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