Improving the format of type annotation attributes

[Alex Buckley]

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
> annotations?

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 
type, etc).

Alex