Clarification Parameter.getName(?)

[Oliver Gierke]

Answers inline…

Am 08.06.2013 um 21:00 schrieb jdk8-dev-request at openjdk.java.net:

> Date: Fri, 07 Jun 2013 16:52:14 -0700
> From: Alex Buckley <alex.buckley at oracle.com>
> Subject: Re: Clarification Parameter.getName(?)
> To: jdk8-dev at openjdk.java.net
> Message-ID: <51B2722E.3020201 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> On 6/7/2013 2:09 AM, Oliver Gierke wrote:
>>> While the MethodParameters attribute can express a parameter with
>>> literally no name, the Core Reflection API follows the precedent of
>>> the Language Model API in SE 6 whereby every parameter is deemed to
>>> have a name.
>> 
>> Does that mean that with Java 6 you'll find parameter names no matter
>> if the code was compile with debug flag or not? What about abstract
>> methods - which according to the JLS - don't carry name information
>> by definition?
> 
> I meant that public signatures in java.lang.reflect don't use types from 
> java.util. This is a longstanding policy.
> 
> I don't understand the question about abstract methods. Their parameter 
> names are no different than parameter names of non-abstract methods. 
> What section of the JLS are you referring to?

Sorry, I mixed up JLS and JVMS. I was referring to §4.7.3:

"Every Java virtual machine implementation must recognize Code attributes. If the method is either native or abstract, its method_info structure must not have a Code attribute."

Now as an interface method is inherently abstract it's currently not carrying the code attribute, hence no name in the LocalVariableTable.

I just wanted to make sure that this exception will not be brought forward to the spec and implementation of -parameters. The current builds resolve interface parameters just fine, so I think we're set here.

>> In Spring Framework we currently use an ASM based approach to lookup
>> parameter names from methods. This approach indicates the absence of
>> the name information by returning null. E.g. the Spring MVC framework
>> allows you to define a method like this:
>> 
>> public String myMethod(@RequestParam Long id) { ? }
>> 
>> With our current approach, we can now discover the request parameter
>> name to be id if the code was compiled with debug flag. But we can
>> fail fast and ask the user to qualify his method signature to:
>> 
>> public String myMethod(@RequestParam("id") Long id) { ? }
>> 
>> We would now like to use the new capabilities of Java 8 if the user
>> is on Java 8. Unfortunately we cannot reliably find out about the
>> case of missing parameter name as we'd simply get arg0 and cannot
>> distinguish between missing name information and a user deliberately
>> wants to do the following:
>> 
>> public String myMethod(@RequestParam Long arg0) { ? }
>> 
>> The only heuristics we can apply is consider everything that matches
>> the arg? pattern indicating a missing parameter name. This feels a
>> bit like a hack. To me it feels like a good use case of
>> Optional<String> (as soon as the lambda branch is in the main builds
>> of course).
> 
> You need Parameter.isNamePresent() which would return false if a 
> parameter's name_index item in MethodParameters is zero (or if there is 
> no MethodParameters attribute at all). I accept that the info is there 
> in the class file - specifically for compilers of non-Java languages - 
> and that it makes sense to expose it. Let me know what you think of that.

Sounds good to me! Any way to find out whether the name was defaulted or is actually present is fine.

> Parameter.getName() should still generate a name when 
> Parameter.isNamePresent() returns false. Consistent availability of 
> names is helpful for some apps, and there is the precedent of the 
> Language Model API generating names for VariableElement#getSimpleName 
> since 2006. Names will get more "truthy" over time as more class files 
> have a MethodParameters attribute.
> 
>>>> Will parameter names be available for interface methods as well?
>>>> Currently they cannot be resolved.
>>> 
>>> Are you saying that interface methods do not have a
>>> MethodParameters attribute generated when -parameters is used at
>>> compile time?
>> 
>> No, I verified the names being present with a current build already.
>> I just asked explicitly as our former ASM-based approach to discover
>> names for interface methods failed due to the fact the names were
>> just not present even if compiled with debug flag (as required by the
>> JLS).
> 
> The JLS doesn't know about debug flags. If you are talking about the 
> LocalVariableTable attribute in the JVMS, then the fact that it resides 
> in the Code attribute is a design flaw for abstract methods since their 
> method_info structures cannot have Code attributes. That's why the 
> MethodParameters attribute lives in method_info, not in the Code attribute.

As stated above, yes I was actually thinking about the JVMS.

Thanks,
Ollie

-- 
/**
 * @author Oliver Gierke - Senior Member Technical Staff
 *
 * @param email ogierke at gopivotal.com
 * @param phone +49-151-50465477
 * @param fax   +49-351-418898439
 * @param skype einsdreizehn
 * @see http://www.olivergierke.de
 */