Parameter reflection without MethodParameters attribute

[Joseph Darcy]

On 12/4/2012 12:20 PM, Alex Buckley wrote:
> The new java.lang.reflect.Parameter class exposes a parameter's 1) 
> name, 2) finality, 3) author (via isSynthetic() and isSynthesized() - 
> if neither is true, then author was human), 4) whether it's a variable 
> arity parameter, 5) annotations, and 6) type.
>
>   Sidebar: If you're wondering about "variable arity parameter",
>   see JLS 8.4.1. The existence of synthetic parameters means that
>   the last Parameter object from Executable.getParameters() might
>   not be the variable arity parameter declared in source, so each
>   Parameter object needs to expose whether it's variable arity.
>
> The methods for (5) return fundamentally the same info as 
> Method.getParameterAnnotations(), so it's clear what to return when no 
> annotation attributes are present: null values and empty arrays.
>
> But the methods for (1)-(4) are tricky when no MethodParameters 
> attribute is available. Should a parameter's name be the empty string, 
> with no modifiers set, and not flagged as synthetic or synthetized or 
> variable arity? And then have an Executable.hasParameterMetadata() 
> method to say whether these values are reliable? Maybe there should be 
> Optional<T> wrappers for parameter info ... only joking, this is not 
> the place to solve Java's "missing value" woes.
>
> I think the best option is to sidestep these questions by having 
> Executable.getParameters() return an empty array if no 
> MethodParameters attribute is available.
>
> SE8 and greater class files may give an empty array, while pre-SE8 
> class files must give an empty array. (The same ought to apply for 
> annotations: in a pre-SE5.0 class file, an attribute called 
> RuntimeVisibleAnnotations means nothing, and ought to be ignored by 
> core reflection, though I have a feeling it will be exposed.)
>

Alternatively, I think it is friendlier for the user for the 
implementation of Executable.getParameters() to manufacture placeholder 
names if none are available, "arg0", "arg1", etc.

This is the policy we use in our implementation of 
javax.lang.lang.model.VariableElement for method and constructor 
parameters when the type is backed by a class file rather than a source 
file.  When a type is backed by a source file, we use the names in the 
source.

-Joe