Improving the format of type annotation attributes

Eric Bruneton ebruneton at free.fr
Sat Sep 22 08:15:16 PDT 2012


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


More information about the type-annotations-spec-comments mailing list