Clarification Parameter.getName(?)

[Oliver Gierke]

(Re-sent with correct subject to fix threading)

Am 07.06.2013 um 05:55 schrieb jdk8-dev-request at openjdk.java.net:

> Date: Thu, 6 Jun 2013 14:25:05 -0700 (PDT)
> From: Alex Buckley <alex.buckley at oracle.com>
> Subject: Re: Clarification Parameter.getName(?)
> To: jdk8-dev at openjdk.java.net
> Message-ID: <51B0FE31.2020100 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> On 6/5/2013 4:28 AM, Oliver Gierke wrote:
>> the Parameter class introduced in Java 8 seems to return "arg0" for a
>> call to getName(), even if the parameter name is not available in the
>> bytecode. This makes it impossible to discover parameter names not
>> being present in the bytecode and potentially taking further action
>> in case names cannot be resolved. Does it make sense to return an
>> Optional<String> to indicate this case?
> 
> 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?

> There is no facility for discovering whether the parameter name 
> was synthesized by the API. Why would it be useful? I'm not sure what 
> "resolution" of parameter names even means.
> 
> As an aside, the Core Reflection API has historically not depended on 
> the broader Java SE API, such as java.util. The Language Model API has 
> no such constraint, and uses java.util widely.

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

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

Cheers,
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
*/