Parameter reflection: duplicate parameter names

[Eric McCorkle]

That comment change should be going in with 8007405

On 02/11/13 14:45, Alex Buckley wrote:
> I have suggested to Eric McCorkle that the javadoc for
> Executable.getParameters should set expectations for clients by saying:
> 
> "The parameters of the underlying executable do not necessarily have
> unique names, or names that are legal identifiers in the Java
> programming language (JLS 3.8)."
> 
> Alex
> 
> On 2/1/2013 12:13 PM, Paul Benedict wrote:
>> Agreed. So shouldn't there be a mention that implementers should not
>> assume parameter names are unique? For example, what you said could
>> easily be attached to the spec to make that clear.
>>
>> Paul
>>
>> On Fri, Feb 1, 2013 at 2:03 PM, Alex Buckley <alex.buckley at oracle.com
>> <mailto:alex.buckley at oracle.com>> wrote:
>>
>>     Core reflection has always exposed what ever is in the class file,
>>     which may always have been generated by a non-Java compiler.
>>     Especially for a new reflective construct which we want non-Java
>>     compilers to use, it is futile to try to constrain core reflection
>>     to hide content which is not Java-compliant, or throw exceptions
>> for it.
>>
>>     Alex
>>
>>
>>     On 2/1/2013 11:47 AM, Paul Benedict wrote:
>>
>>         I know parameter names are irrelevant to the JVM, but the spec
>>         doesn't
>>         explain how this poor situation will be handled. Should it at
>>         least be
>>         mention it's expected for all names to be unique? Or leave the
>>         behavior
>>         undefined? It might matter to the implementator -- especially
>> if a
>>         HashMap<> could be used internally to store the names.
>>
>>         Paul