Spec updates for method parameter reflection

[Alex Buckley]

On 11/12/2012 2:35 PM, Leonid Arbouzov wrote:
> What would be conformance requirements for this feature?

Essentially: if the MethodParameters attribute is present in ClassFile 
of v52.0 or above, it must be interpreted by the reflection libraries of 
the Java SE platform in the appropriate way. The attribute has no effect 
on the runtime behavior of the attributed class itself. The attribute is 
much like the attributes for annotations.

> For example, would a Java compiler be in conformance
> with the spec in the following cases:
> - the compiler generate parameter names by default for all classes (no
> way to suppress it),

Yes.

> - the compiler ignores the option controlling parameter names generation
> (no way to turn it on),

Yes. (A compiler ignoring its own command-line option doesn't seem very 
well behaved though.)

> - the compiler generate parameter names selectively (let's say for
> public methods only),

Yes.

> - the compiler supports private (implementation-specific) annotations
>    controlling parameter names generation,

Yes. The very strong traditional guidance is that an annotation must not 
cause the runtime behavior of code to differ from that specified in the 
JLS. It is acceptable if an annotation merely causes a MethodParameters 
attribute to be generated, because as above, the attribute does not 
affect the attributed's class runtime behavior.

> - the compiler somehow modifies parameter names (let's say prefixing
> with... "param_").

Yes. Since the reflection libraries have no source code available, they 
cannot prove that the parameter names being read from a MethodParameters 
attribute are anything other than what was in source.

> BTW,  compared with an option approach @ReifyParameters annotation
> could allow more accurately specify and check Java compiler behavior
> ...if it is important in that case.

Yes. But we are deliberately avoiding an in-language mechanism (testable 
by a conformance suite) at this time.

Alex