Spec updates for method parameter reflection

[Remi Forax]

On 11/12/2012 08:10 PM, 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

I have thought about that ones (above) too.

> - 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.

It's a question that should be asked during Devoxx, after all you have a 
lot of developer minds available during that week,
a consensus may appear.

> For this reason, we will avoid defining a standard "opt in" mechanism 
> for Java SE 8.

If there is no default opt in, I think we should withdraw that feature 
from Java 8.
There are two problems, if you don't provide a default, either nodoby 
will use it
because it's no reliable, you can already extract local variable table 
from the bytecode,
so you can have the name of the parameters, but because you need to opt-in
to have debug information, it's not reliable for people that write 
bytecode enhancer
or use reflection to implement meta protocols.
Or the default opt-in will be vendors or tools specific, and it will be 
a mess.
"Oh, you have compiled with ant/maven, that's why it doesn't work, you 
should use
whateverIsTheNameOfTheVendorTool to enable EJB/REST/etc implementation 
to work".

so if it's too hard to find a consensus on what should be the default 
opt-in,
it's better to don't include that feature in Java 8,
people will reify the parameter name by hands as they do now but at 
least it will work for everybody.

>
> Alex

Rémi