Spec updates for method parameter reflection

Leonid Arbouzov leonid.arbouzov at oracle.com
Mon Nov 12 14:35:30 PST 2012


What would be conformance requirements for this feature?

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),
- the compiler ignores the option controlling parameter names generation 
(no way to turn it on),
- the compiler generate parameter names selectively (let's say for 
public methods only),
- the compiler supports private (implementation-specific) annotations
   controlling parameter names generation,
- the compiler somehow modifies parameter names (let's say prefixing 
with... "param_").

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.

Thanks,
-leonid

On 11/12/2012 11:10 AM, Alex Buckley wrote:
> On 11/10/2012 4:40 AM, Remi Forax wrote:
>> I think the default policy (don't include parameter names) is not the
>> good one. While I agree that enable reified parameter everywhere can
>> severely impact class file size (the runtime part can be lazy), there
>> is a third option between enable and disable, enable parameter names
>> selectively.
>>
>> I propose the following default policy, parameter names are enabled
>> by default only if the methods is annotated with an annotation with
>> the retention CLASS or RUNTIME.
>>
>> The idea is that if the method is annotated, the parameter names
>> should be visible by a class enhancer or the reflection API.
>
> There are many ideas for an "opt in" mechanism:
>
> - Explicit: @ReifyParameters annotation on a class
> - Explicit: @ReifyParameters annotation on a method
> - Semi-explicit: @ReifyParameters meta-annotation on a class annotation
> - Semi-explicit: @ReifyParameters meta-annotation on a method annotation
> - Implicit: Presence of any RUNTIME-retention annotation on a class
> - Implicit: Presence of any RUNTIME-retention annotation on a method
> - Implicit: Presence of any CLASS/RUNTIME-retention annotation on a class
> - Implicit: Presence of any CLASS/RUNTIME-retention annotation on a 
> method
>
> Opinions differ on which is best. It seems risky at this time to 
> commit to one mechanism, since it would have to be supported forever 
> even if consensus comes round to a different mechanism. For this 
> reason, we will avoid defining a standard "opt in" mechanism for Java 
> SE 8.
>
> Alex



More information about the enhanced-metadata-spec-discuss mailing list