Improving the format of type annotation attributes

[Michael Ernst]

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