Clarification Parameter.getName(…)

[Alex Buckley]

John,

I propose to satisfy reflection of Java parameters (names are not 
meaningful, but always extant) _and_ non-Java parameters (names are 
meaningful, even if not extant) by:

1. Continuing to have Parameter.getName always return a name, even if 
synthesized.

2. Adding Parameter.isNamePresent to return false if a parameter's 
name_index item in MethodParameters is zero (or if there is no 
MethodParameters attribute at all).

I plan to file a CCC request for this very soon, so please let me know 
what you think.

Alex

On 6/6/2013 4:40 PM, John Rose wrote:
> Because Java parameter names in API methods are never semantically meaningful, it is always valid to replace a missing name with an arbitrary one.  The envisioned uses for this API are evidently only human readable output, since otherwise the arbitrary replacement of no name by argN would be a risky ambiguity.
>
> With other languages, parameter names are sometimes semantically significant, such as for keyword based calling syntaxes.  In those cases, parameters named argN will have to be specially escaped to distinguish them from missing names. And it disadvantages names like argN even for Java APIs when other languages would interoperate with them.
>
> I suppose there are good reasons for helping printing code supply missing parameter names. But it does burden other uses.
>
> -- John  (on my iPhone)
>
> On Jun 6, 2013, at 2:32 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
>
>> Thomas and Oliver,
>>
>> I draw your attention to the thread "Parameter reflection: parameters with "" as their name" on the enhanced-metadata-spec-discuss list in January:
>>
>> http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-January/thread.html
>>
>> and to the "4.2.2 Unqualified Names" section of the enhanced metadata spec.
>>
>> Alex
>>
>> On 6/5/2013 4:53 AM, Oliver Gierke wrote:
>>> I know, but this feels like a hack and I wonder if it makes sense to expose that scenario into the method signature :).
>>>
>>> Am 05.06.2013 um 13:44 schrieb Thomas Darimont <thomas.darimont at googlemail.com>:
>>>
>>>> Hello Oliver,
>>>>
>>>> In order to determine whether the "real" parameter names are present on the given Method,
>>>> you could check via reflection whether the name attribute of the Parameter instance
>>>> is null or an empty String.
>>>>
>>>> See the implementation of getName() in java.lang.reflect.Parameter:
>>>>
>>>>      public String getName() {
>>>>          // Note: empty strings as paramete names are now outlawed.
>>>>          // The .equals("") is for compatibility with current JVM
>>>>          // behavior.  It may be removed at some point.
>>>>          if(name == null || name.equals(""))
>>>>              return "arg" + index;
>>>>          else
>>>>              return name;
>>>>      }
>>>>
>>>> Best regards,
>>>> Thomas
>>>>
>>>>
>>>> 2013/6/5 Oliver Gierke <ogierke at gopivotal.com>
>>>> Hi all,
>>>>
>>>> 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?
>>>>
>>>> Will parameter names be available for interface methods as well? Currently they cannot be resolved.
>>>>
>>>> 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
>>>>   */
>>>