about the 'location' field definition for nested types in Section 3.3.11

[Eric Bruneton]

Hi,

Consider these examples from Section 3.3.11:

@A Map<@B ? extends @C String, @D List<@E Object>>
@I String @F [] @G [] @H []
@A Map<@B Comparable<@C Object @D [] @E [] @F []>, @G List<@H Document>>

The corresponding signatures are 
(http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.3.4):

LMap<+LString;LList<LObject;>;>;
[[[LString;
LMap<LComparable<[[[LObject;>;LList<LDocument;>;>;

And if we put the annotations before their target in these signatures, 
we get:

@A LMap< @B + @C LString; @D LList< @E LObject;>;>;
@F [ @G [ @H [ @I LString;
@A LMap< @B LComparable< @D [ @E [ @F [ @C LObject;>; @G LList< @H 
LDocument;>;>;

We can see that they appear, from left to right, in the same order as a 
preorder traversal of the trees in Figure 2. However, consider now the 
examples using nested types:

@M O1. at L O2. at K O3. at J NestedStatic
@A O1. at B O2<@C S, at D T>. at E O3. at F Nested<@G U, @H V>

LO1.O2.O3.NestedStatic;
LO1.O2<TS;TT;>.O3.Nested<TU;TV;>;

@J L @M O1. @L O2. @K O3. NestedStatic;
@F L @A O1. @B O2< @C TS; @D TT;>. @E O3. Nested< @G TU; @H TV;>;

We can see that the annotations no longer appear, from left to right, in 
the same order as the preorder traversal of the trees in Figure 2.

I think it would be useful to ensure this property also for nested 
types, for two reasons:
- this ordering is what we would naturally get if the definition of 
'location' was based on signatures. Given that all other elements are 
defined based on the class file format representation of their target 
(for instance a bytecode offset, or an index into an exception table), I 
would find it more logical to also define 'location' with respect to the 
bytecode representation of generic types, i.e. with respect to the 
grammar used for Signature attributes. This would make their definition 
independent of the Java syntax for type annotations, that other 
languages may not reuse (cf my previous email about non Java languages).
- with this ordering, given a 'location' value, we can easily find the 
corresponding signature subpart with a simple 'stateless' left to right 
parsing of the signature. With the current ordering, we need to build 
the corresponding tree first.

Therefore, I'm wondering if the ordering of the children for nested 
types could be reversed in the specification. This would mean replacing

"For a nested type, the children are the type arguments (if any), 
followed by the outer types, numbered from innermost to outermost."

with

"For a nested type, the children are the outer types, numbered from 
outermost to innermost, followed by the type arguments (if any)."

and updating the figures accordingly.

Eric