[type-annos-observers] Constraining type annotations to occur just before type
Markus Keller
markus_keller at ch.ibm.com
Wed Apr 24 02:56:00 PDT 2013
Since TYPE_USE is new in SE 8, this whole discussion is not about
traditional source compatibility when moving from SE n to SE n+1. Of
course, all SE 7 code still needs to compile unchanged in SE 8. And I'm
not proposing anything that would affect this scenario.
The discussion is only about annotation types that are changed by adding
TYPE_USE as target. Compare this to a parameterized type: Adding another
type parameter is a breaking change. The provider of the type can do it,
but its users must face the consequences.
> It's not ideal, but the alternative of breaking source compatibility is
> worse. All a new SE 8 annotation processor (that is, a processor which
> uses the new SE 8 reflection methods) has to do - until such time as the
> annotation type's provider makes TYPE_USE the sole target - is detect
> that NonNull is a legacy annotation type and react accordingly.
Removing a declaration target from an existing annotation is always a
breaking change. Old annotation types better make a clear cut and break
compatibility now, rather than trying to stay compatible with old versions
and only break their clients in a later release.
> > The superficially supported combination of TYPE_USE and declaration
targets
> > creates horrible corner cases for every user of such an annotation
(even
> > those who only started to use them with SE 8 or later).
>
> No! Not for "every user" of an annotation. Be precise, please. It
> creates corner cases for the handful of people who write annotation
> processors. Everyone who applied the annotation is fine.
No, it not only affects writers of annotation processors. Since the
annotation processor has to implement convoluted semantics, it also
affects people who just want to apply the annotation. Not every user may
run into the corner cases immediately, but the corner cases are there for
every user.
> No, the language should not seek to organize different kinds of
> annotations. An annotation type like NonNull has semantics -
> specifically regarding inheritance, repeatability, and targetability -
> but an @NonNull annotation has no meaning in the language so the
> language should not prescribe whether it appears before or after
> 'public'.
All type-use annotations share one part of their semantics: They belong to
the annotated type.
> The JLS can certainly _recommend_ that type annotations appear
> in one place and declaration annotations appear somewhere else, but
> enforcement is a matter for tools.
Just because type-use annotations look the same as declaration annotations
doesn't mean they have to be treated the same. Like the JLS forces me to
write modifiers in front of the type of a field (and not e.g. in front of
the field name, which would be easily acceptable for a parser), it can
also enforce annotation positions.
It all boils down to the question whether adding TYPE_USE should be
considered a compatible change or not.
- pro "incompatible": avoid the mentioned inconsistencies and be free to
add helpful positional restrictions
- pro "compatible": try to be helpful to providers (and users) of
annotations that abused declaration annotations as type-use annotations
and now try to get away without source changes
I value a consistent story higher.
Regards,
Markus Keller
IBM Rational Zurich Research Lab
Eclipse JDT UI lead
More information about the type-annotations-spec-observers
mailing list