[JSR308] Postfix syntax for type annotations

Eugene Kuleshov eu at javatx.org
Tue Jan 30 21:07:20 EST 2007

Michael Ernst wrote:
>   Consider separating type annotations from all other annotations, and put
>   them in a different place in the syntax. For example, one could write
>   type annotations after the type. In
> 	  @A Type @B var;
>   @A would refer to the variable and @B would refer to the type. One
>   advantage is that this makes the syntax for type annotations more uniform
>   (no special cases in the grammar for return values or arrays of arrays),
>   and may make the syntax less confusing, especially for arrays. One
>   disadvantage is that programmers must remember which annotations are type
>   annotations and which are not, which may be confusing. Another issue is
>   that this proposal is not backward-compatible: it is inconsistent with
>   existing annotations proposed by JSR 305, such as @NonNull.
  That reminds me that we will need to update 
java.lang.annotation.ElementType enum with new element types supported 
by jsr 308.
>> Well, annotations before the annotated type doesn't work, because in a
>> simple variable declaration it is ambiguous with an annotation on the
>> variable.
> I don't think this is likely to be ambiguous:  some annotations refer to
> types, and some to variables, and I expect that it will be clear to
> programmers which is which.  But maybe others can come up with an example
> where this would be a problem in practice.
  I wonder if it is safe to assume that if annotation for the local 
variable/field is there, then annotation for its type is assumed to be 
the same. Right now I can't think of example where is is useful to have 
annotation on the Java type separate from annotation on the value 
(stored into the variable or field).

  Then it will be enough to have only annotation on variable/field and 
not on its type, which would eliminate need in things like @A Type @B 
var, that can be replaced with @A @B Type var (though A and B could 
still be declared on the different element types), as long as this info 
is preserved in the bytecode.


More information about the JSR308 mailing list