[JSR308] array-valued annotations

[Joe Darcy]

Ted Neward wrote:
>>> I think I see Pavel's point, though; the declaration "doc" implicitly
>>> suggests that all of the dimensions to the "jagged" array behind the
>>> reference are of the same type (Document).
>> I presume you mean all the values, not all the dimensions.
>>
> No, in this case, I meant dimensions, but in the more loosely-based notion
> that the arrays are based around the Document type. (I'm not speaking of the
> Document vs. Document[] vs. Document[][] as being separate types for
> purposes of this discussion.)
> 
>> Correct.  But using this notation,
>>    Document [][] doc
>> means
>>    Document [Document[]] doc
>>
>> And we find that, unfortunately, Java programmers like to sometimes
>> make the outer Document[] type different than the inner Document[];
>> i.e., one might permit null elements and one might not.
>>
> Ew; count me out of that crowd.
> 
>> To me, supporting type annotations in Java means supporting
>> annotating *all* of the types one can declare in Java, not just some
>> of them.
>>
> Does that include the types that are created by the Dynamic Proxy class? Or
> the primitive types themselves? I hate to say it, but the array types are
> referred to as "pseudo-types" for a reason.
> 
>> Doesn't this represent a fairly conservative view of what constitutes
>> a type?  I certainly consider such annotations as part of the type
>> signature.
>>
> Conservative or not, two classes whose only differentiation (including name)
> is the presence or lack thereof of an annotation, is illegal. The presence
> or absence of an annotation does not show up in the JVM-level signature, and
> therefore cannot be used to differentiate in method overloading. Ditto for
> fields. The annotation is not part of the signature, and to change that
> would be a fairly drastic change throughout the JVM, I would think.
> 
> Let's not create a JSR that's unworkable for the implementors. Joe, assuming
> this JSR goes to Final status, who would be implementing this in the JVM and
> related tools?

I'll let Danny handle that question :-)

However, the JSR's stated scope:

"This proposal does not change the compile-time, load-time, or run-time 
semantics of Java. It does not change the abilities of Java annotation 
processors. The proposal merely makes annotations more general --- and 
thus more useful for their current purposes, and also usable for new 
purposes that are compatible with the original vision for annotations."

excludes any fundamental changes in the JVM's operation.  If the new 
kinds of annotations are exposed to runtime core reflection somehow, 
that will at least require a nominal JVM change to expose the new class 
file attribute.

(I'm working on a blog post describing the surprising long list of 
issues to consider when evolving the Java programming language.  I'll 
send it around for comment once its further along.)

[snip]

-Joe