[JSR308] Annotations on type variable declarations

Niko Matsakis niko at alum.mit.edu
Wed Feb 25 05:57:37 EST 2009

My two cents:

> * ElementType.TYPE_USE permits @Anno1, @Anno2, and @NonNull.
>   A type variable declaration is not really a use of a type, so in  
> this
>   design the name TYPE_USE is a bit of a misnomer and may be  
> confusing.
>   It could perhaps be renamed to, say, ElementType.TYPE_ANNOTATION.

To me, TYPE_ANNOTATION doesn't describe a semantic category of  
locations, but rather simply segregates the new JSR-308 locations.    
That doesn't seem desirable, so I would vote against this option.

>  * ElementType.TYPE permits @Anno1.
>   ElementType.TYPE_USE permits @Anno2 and @NonNull.

While this option fits semantically, I would guess most annotations  
are only valid on genuine types or interfaces, not type variables, so  
it does seem that this would oblige most annotation processors to do  
more checking than they already do.

There are numerous ways that type parameters are different from other  
* Most types can be named from outside the class, but type parameters  
* Type parameters are erased.
* Type parameters cannot have type parameters.
* etc

> * new enum constant ElementType.TYPE_PARAMETER permits @Anno1.
>   ElementType.TYPE_USE permits @Anno2 and @NonNull.

I personally prefer this option as it is the most descriptive, and I  
believe TYPE_PARAMETERs are sufficiently different from other TYPEs to  
warrant separate treatment.

It does impose a slight burden of annotation authors who must parse a  
large list of ElementType options.  On the other hand, the overall  
burden may be lower because it would not be necessary to check in the  
code of an annotation processor that the annotation is correctly placed.

> I don't think it makes sense to distinguish between the locations
> exemplified by @Anno2 and @NonNull.


> PS:  JSR 308 supports annotations on type variable declarations  
> because
> people have found uses for it.  If those other people can remind me of
> those uses, I'll note them in the design document.  That will also  
> make our
> discussion more concrete.

I use such annotations to indicate class region parameters whose value  
ought to be inferred based on the value of the type variable.  For  
example, vector might be declared:

	class Vector<@JPartParams("@P") E extends @P Object> { ... }

In this case, the class Vector has two region parameters, @V and @P.   
@V is the region of the vector, and @P is the region of the elements  
inside the vector.  @P is not specified explicitly by the user, but is  
instead derived for any instance of Vector based on the value of E.   
For example: a type like "@Q Vector<@R Object>" would have "@P" bound  
to "@R".  A type "@Q Vector<String>", on the other hand, would have  
"@Q" bound to "@RO", because all strings are in the "@RO" (read-only)  
region.  Without such inference, those two types would have to be  
specified as: "@Q @R Vector<@R Object>" and "@Q @RO Vector<String>",  

Hopefully that's clear.  Let me know if you need additional details or  


More information about the JSR308 mailing list