mahmood at MIT.EDU
Wed Aug 20 05:24:35 EDT 2008
Thank you for the specification clarification requests. I will add
this to my TODO list.
> A couple of items:
> AnnotationUtils.isSame assumes that two annotation are the same if
> their toString values are the same. The implementation of
> AnnotationBuilder's annotation returns a different string format.
Thanks. It's a petty that AnnotationUtils.isSame uses .toString. We
should try to use .equals when we can. I will work on this (It should
be in within two releases).
> AnnotatedTypeMirror.addAnnotation does not state the behavior if the
> annotation to be added already exists, but with different element
> values. The current implementation does remove the existing
> annotation, it is necessary to manually remove a previous one before
> adding a new one.
I am indifferent to whether the first add overrides subsequent ones or
the last one overrides the ones before. Personally, I view it as a
map of annotations mapped to their values; where the last .put()
operation overrides the previous ones.
> For me the best implementation would be to ask the typeFactory to
> combine the annotations, whereas the default implementation would
> throw an exception if the values did not match (or possibly a more
> sophicated implementation that would attempt to combine array values
> if possible).
Personally, I do not think that is a reasonable functionality in the
> AnnotatedTypeMirror removeAnnotation removes annotations based on
> the annotation's type, ignoring any values. The spec is not clear on
I will clarify this point.
> Maybe multiple annotations of the same type on an element is still
> on the table?
Unfortunately, not. A change in the language specification is needed
to allow multiple annotations of the same declared type annotate a
type. This is useful in cases like @DefaultQualifier where multiple
@DefaultQualifier could signify multiple defaults.
More information about the checkers