Improving the format of type annotation attributes

[Michael Ernst]

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