[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