Improving the format of type annotation attributes

[Alex Buckley]

Thanks Mike. Could you post the URLs to the PDF and HTML versions here 
please? The links in the changelog are broken.

Alex

On 11/7/2012 10:26 AM, Michael Ernst wrote:
> I have now updated the specification to account for the type_path
> representation of compound types.  This made the spec shorter and simpler,
> which is nice.  The changelog is at
> http://jsr308-langtools.googlecode.com/hg/doc/jsr308-changes.html but
> you'll want to see the actual spec in the repository instead.  (Let me know
> if you want me to send you a formatted HTML or PDF version.)  Comments are
> welcome, as always.
>
> 		    -Mike
>
>
>> Subject: Re: Improving the format of type annotation attributes
>> From: Michael Ernst <mernst at cs.washington.edu>
>> To: type-annotations-spec-experts at openjdk.java.net
>> Date: Tue, 06 Nov 2012 13:07:33 -0800 (PST)
>>
>> Eric Bruneton made the following suggestion about restructuring the class
>> file format for
>>
>> This approach combines elements of earlier proposals by John Rose, Alex
>> Buckley, Eric Bruneton, and others.  It seems to be the right mix.  I am
>> editing the JSR 308 specification to specify the below class file format
>> (though some of the names in the union have subsequently changed).
>>
>> Thanks, Eric!
>>
>> 		    -Mike
>>
>>
>>
>>> Subject: Re: Improving the format of type annotation attributes
>>> From: Eric Bruneton <ebruneton at free.fr>
>>> To: type-annotations-spec-comments at openjdk.java.net
>>> Date: Sat, 22 Sep 2012 17:15:16 +0200
>>>
>>> I have one comment about the "fully nested" format proposed by John
>>> Rose. As noted by Alex Buckley this is an "inside-out" encoding for all
>>> kinds of targets. For reasons that I explained previously, I think it would
>>> be better to have an outside-in encoding for all targets. This can be done
>>> with a "nested" approach too, as follows:
>>>
>>> type_annotation {
>>>      // New fields in JSR 308:
>>>      u1 target_type; // CHANGE: u1 and remove the 18 odd types
>>>      union {
>>>          typeparam_target;
>>>          supertype_target;
>>>          typeparam_bound_target;
>>>          empty_target;
>>>          methodparam_target;
>>>          exception_target;
>>>          localvar_target;
>>>          catch_target;
>>>          offset_target;
>>>          typearg_target;
>>>      } target_info;
>>>      type_path target_path; // ++ADDED, see below
>>>      // Original fields from "annotation" structure:
>>>      u2 type_index;
>>>      u2 num_element_value_pairs;
>>>      {
>>>          u2 element_name_index;
>>>          element_value value;
>>>      } element_value_pairs[num_element_value_pairs];
>>> }
>>>
>>> ADDED structure:
>>>
>>> struct type_path {
>>>      u1 path_type; // five possible values, one for each case below
>>>      union {
>>>          struct empty_path {};
>>>          struct array_type_path { type_path subpath; };
>>>          struct inner_type_path { type_path subpath; };
>>>          struct wildcard_path { type_path subpath; };
>>>          struct type_argument_path { u1 parameter_index; type_path subpath; };
>>>      }
>>> }
>>>
>>> In this way we have the annotation target first, from most significant to
>>> least significant parts, followed by the annotation value. From the ASM
>>> point of view, both this proposed format and the current "counted" format
>>> (with nested types numbering reversed) would be fine.
>>>
>>> Eric