[JSR308] array-valued annotations

Michael Ernst mernst at csail.mit.edu
Sun Jan 28 18:49:26 EST 2007


Thanks for raising these concerns.  It's important for us to consider the
ramifications of any design that we consider.

> > ... consider an array of type Document[][].
> > 
> >  * The first level of the array has type Document[][].
> >  * The next level (i.the first level's elements) has type Document[].
> >  * The final level (the leaves) has type Document.
> > 
> > These are distinct types, though Java enforces that they have a
> > specific relationship to one another.
> At runtime these specific constraints are enforced via a store check 
> that relies on reified information about the array's type.

No, the relationship among these types is enforced at compile time.
On the other hand, properties of values (such as their run-time
classes) are enforced at run time.

Facts about annotations might be enforced at compile time or at run
time.  An approach involving reification of annotation information
would have the difficulties that you noted, but that is not the only
enforcement approach.  Such an approach might not even make sense for
certain types of information, such as type qualifiers.  Finally, JSR
308 explicitly states that it does not endorse such an approach.

> I believe 
> adding similar reification of annotation information would be 
> problematic and at compile time only accepting programs that didn't need 
> such runtime checks would be too incompatible.

When you speak of "accepting programs", are you talking about the
compiler or about some specific compiler plug-in (that is, annotation
processor)?  I agree that the compiler should not reject a program
based on its annotations.  What a plug-in does is up to the plug-in
author.  (That person is best off to choose semantics that will be
compatible with other classes.)  Perhaps I am misunderstanding, but it
seems that your concerns are about specific types of plug-ins and
specific implementation strategies for those plug-ins.  I concur with
your comments in that context.

> Even if such retrofitting is not done (and not intended), the 
> complications of having fundamentally different de facto typing rules 
> for arrays types with certain kinds of annotations and array types 
> without those annotations is undesirable (even if it is necessary).
> During JDK 5 development, the rules for combining arrays and generics 
> evolved, but they are still a source of complexity and confusion. 
> Adding news rules for annotations could exacerbate the situation.

This overview of your concerns is quite valuable.  One thing that
might be helpful for members of the mailing list is to make these
points explicit.  Can you also give specific examples of problems that
were addressed in the past (and how they were addressed) and how they
would be exacerbated, or new problems that you expect to arise?  Can
you give specific examples of what sorts of programs would be
incompatible or would be rejected unnecessarily?  With these details,
we can proceed with a technical discussion.  That will let us either
work to address the problems or recognize that they are insoluble and
abandon a flawed design.


                    -Michael Ernst
                     mernst at csail.mit.edu

More information about the JSR308 mailing list