Initial spec for Repeating Annotations and Method Parameter Reflection

Rémi Forax forax at univ-mlv.fr
Tue Aug 21 06:57:06 PDT 2012


On 08/17/2012 11:24 PM, Alex Buckley wrote:
> Metadata fans,
>
> Oracle engineers have been working on Repeating Annotations and Method 
> Parameter Reflection for a number of months.
>
> The design, specification, and implementation of Repeating Annotations 
> is considerably advanced. We have a language specification and a 
> detailed example-led description of how repeating annotations are 
> compiled and how java.lang.reflect.AnnotatedElement can be improved.
>
> Method Parameter Reflection (I use this title because the feature is 
> more than just parameter names) is much less advanced. We have a 
> ClassFile specification to record parameter information, but many 
> questions about the recording of parameter names are yet to be asked, 
> let alone answered.
>
> I have consolidated all available material into a single, 
> spec-licensed PDF:
>
>   http://cr.openjdk.java.net/~abuckley/8misc.pdf
>
> Please send substantive technical comments about the material to this 
> list.
>
> In the next few weeks, the implementation of Repeating Annotations 
> should appear in the jdk8/tl forest, and we will start thinking about 
> core reflection and language model (JSR 269) APIs for method parameters.
>
> If you are wondering whether Repeating Annotations interact with Type 
> Annotations, you are right. An annotation on a type use should be 
> repeatable just like an annotation on a declaration. The JSR 308 team 
> is aware of this and will raise it with the JSR 308 Expert Group soon, 
> followed by R.I. work in the Type Annotations Project.
>
> Alex

Hi Alex, Hi all,
I've just read the chapter 1,
there is a small bug in the draft, section 9.6.3.8 (page 6 of the draft),
ContainedBy is spelled ContainerAnnotation in the java code provided.

In section Reflection, you forget to talk about the behavoir of 
isAnnotationPresent(),
even if there is no big deal.

Now, I don't see why @ContainerFor is needed, given that the compiler 
and the reflection runtime can use already existing information (the 
return type of value()) to reconstruct the information given by 
@ContainerFor.

cheers,
Rémi




More information about the enhanced-metadata-spec-discuss mailing list