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 <[email protected]>:
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 <[email protected]>
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 [email protected]
* @param phone +49-151-50465477
* @param fax +49-351-418898439
* @param skype einsdreizehn
* @see http://www.olivergierke.de
*/
