u1 vs. u2 in JSR 308 classfile format

[Alex Buckley]

There is some subtlety here. Please confirm the following is acceptable:

u1:

- In the Java language and in the Signature attribute, generic class and 
method declarations are not limited to 255 type parameters, nor are 
parameterized class and method invocations limited to 255 type 
arguments. However, 255 type parameters ought to be enough for a generic 
type, just like 255 dimensions are enough for an array type. So, I have 
no problem with u1 for type_parameter_index and bound_index.

(This is consistent with type_path_entry.type_argument_index being a u1. 
Speaking of compound types, a u1 for type_path.path_length is fine - 
John Rose said earlier that type expression trees are never so deep as 
to require a u2 length field.)

- In a method descriptor, the number of formal parameters is limited to 
255, so u1 is appropriate for method_parameter_index.

u2:

- In ClassFile, the number of supertypes is a u2, so u2 is appropriate 
for supertype_index.

- In the Exceptions attribute, the number of exceptions is a u2, so u2 
is appropriate for throws_type_index.

Alex

On 12/22/2012 9:13 PM, Michael Ernst wrote:
> The JSR 308 class file format contains what seems like a rather haphazard
> choices between u1 and u2, for values that we expect to be small as a rule:
>
>      type_parameter_target {
> 	u1 type_parameter_index;
>      };
>
>      supertype_target {
> 	u2 supertype_index;
>      };
>
>      type_parameter_bound_target {
> 	u1 type_parameter_index;
> 	u1 bound_index;
>      };
>
>      method_parameter_target {
> 	u1 method_parameter_index;
>      };
>
>      throws_target {
> 	u2 throws_type_index;
>      };
>
> (By contrast, it's good to use u2 for indices into code, exception tables,
> etc.)
>
> Should all of these be made u1?  This is a rather minor issue either way.
>
> 		    -Mike
>