[JSR308] A simple proposal for recursive annotations

[Jonathan Aldrich]

>> (because the annotations in the static checking system may be
>> parameterized in different ways than Java type parameterization).
> 
> I admit this strikes me the same way as it struck an earlier poster.  It 
> looks like a bad trajectory for the annotation language to be 
> significantly more sophisticated than the annotated language.

Sorry, I wasn't proposing anything more than just the ability to build 
up annotations recursively, like any recursive data structure in Java. 
It turns out that's enough to encode parameterization in 
annotation-based type systems.  If you thought I was proposing adding 
"native type parameters" to annotations, well, that would be interesting 
but as you say is clearly outside the scope of the JSR.

For examples of where you might want to encode "annotation parameters" 
in different places in a library than already have type parameters, see 
my earlier message to the list.


> If the annotation language seems too constraining, I would propose what 
> we did for Scala's annotations.  Specifically, Scala allows arbitrary 
> expressions to be embedded within the annotations.  That approach keeps 
> the annotations group from becoming a general-purpose language design 
> group, it allows a very general language of annotations, and it provides 
> synergy with the underlying language.  As one example of this synergy, 
> someone designing an a set of annotations can arrange that evaluating 
> the embedded expression would give a run-time representation of an 
> equivalent type.

That would be great, both in terms of expressiveness and a nicer syntax 
for saying complex things.  But I think it would also be a much bigger 
change than recursive annotations, which are uglier syntactically but 
can at least express what you want....


> All this said, it first seems important to accomplish 308's main task of 
> allowing annotations on types at all.  Extending the set of annotations 
> is a further step beyond the main scope, isn't it?

There are a set of annotation expressiveness tweaks already in the 
proposal which are not directly "allowing annotations on types" but are 
supportive of that.  I'd put recursive annotations in that category, 
with the justification of encoding annotation parameterization and/or 
mimicking/shadowing the existing (recursive) structure of types in Java. 
  It's a judgment call--but my sense is that if we can figure out the 
details, this is a high-value addition and is as well in scope as other 
items in the current proposal.

Jonathan