[JSR308] Default annotations
Michael Ernst
mernst at csail.mit.edu
Sat Feb 24 21:38:10 EST 2007
Specifying a default for annotations can reduce code size and (when used
carefully and sparingly) increase code readability.
For instance, Figure 1 of the JSR 308 proposal (which is available at
http://pag.csail.mit.edu/jsr308/java-annotation-design.pdf
http://pag.csail.mit.edu/jsr308/java-annotation-design.html
) uses @NonNullDefault to avoid the clutter of 5 @NonNull annotations.
But it would be nicer to have a general mechanism, such as
@DefaultAnnotation(NonNull.CLASS, locations={ElementType.LOCAL_VARIABLE})
It would be even better to be able to specify the arguments to the
defaulted annotation, as in
@DefaultAnnotation(@MyAnnotation(arg="foo"))
but that is not currently possible -- we would have to extend the Java
syntax in a new way to accommodate it.
Should the issue of default annotations be taken up by us (JSR 308) or by
JSR 305? (Recall that JSR 305 is defining a set of annotations, along with
their semantics. For instance, it is JSR 305's role to decide whether Java
programmers will write @NonNull or @Nonnull or @NotNull, and what it means
when they write it.)
If a clean solution is possible using existing Java syntax, then JSR 305
should probably handle the issue. But if existing Java syntax requires a
hack, then it may be preferable for us to make (modest!) changes to Java
syntax to accommodate a clean solution, rather than enshrining that hack in
JSR 305.
My feeling is that for now, we should sit tight and see what JSR 305 comes
up with. I just wanted to appraise the JSR 308 community of the issue.
(A related issue is inheritance of annotations in subclasses and overloaded
methods. Because this depends on the annotation -- some should be
inherited and some should not -- it doesn't make sense to set a single
standard, and in any event it is a semantic issue that is not in scope for
JSR 308.)
-Mike
More information about the JSR308
mailing list