Spec updates for method parameter reflection

[Leonid Arbouzov]

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

A compiler of XYZ company may want to  ignore -g:parameters option
of JDK's javac  with well intentions -  just trying  to be more option 
compatible...

Anyway, thanks for your answers.
This makes it clear that the option indeed similar to -g option of javac
and thus not a subject of Java compiler conformance testing...

Could this create some compatibility problems?
For example,  one replaces Java+compiler version with
other version and discovers that it's product fails at runtime because
parameter names info missed? Would it be of any concern?
Does it mean we care mostly about runtime compatibility in that case?

Thanks,
-leonid

On 11/12/2012 2:49 PM, Alex Buckley wrote:
> 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