Improving the format of type annotation attributes
alex.buckley at oracle.com
Thu Sep 13 13:50:56 PDT 2012
On 9/13/2012 1:12 PM, Doug Lea wrote:
> On 09/13/12 15:31, Alex Buckley wrote:
>> Then we must make a choice. The low-risk approach is simply to
>> move the location information earlier in the type_annotation
>> structure. The high-risk approach is to drop the "counted" approach
>> to location information and adopt the "nested" location approach.
> Where "risk" amounts to throwing away and redoing part of the
> current reference implementation that encodes and decodes
Yes, and also fitting the implementation of the core reflection +
language model APIs around the new ClassFile encoder/decoder.
We have only a few months remaining; JDK 8 is scheduled to be Feature
Complete in January 2013, per http://openjdk.java.net/projects/jdk8/.
> I'm not sure that anyone not involved in encoding/decoding (not me)
> can give much guidance, but offhand, the nested approach looks more
> amenable to addressing some of the comments posted by Eric Bruneton?
Eric's issue with the location field is that it encodes nested types
inside-out. Outside-in would be more congruent with Signature
attributes. John's nested approach is actually inside-out for _all_
kinds of type constructors:
- the . nested type constructor
- the  array type constructor
- the <...> non-wildcard type argument constructor
- the ? ... wildcard type argument constructor
because the final enclosing target_info is the logical location where
the annotated type appears (type parameter, field type, method return
More information about the type-annotations-spec-experts