Summary

Stop caching the synthesized names in synthesized java.lang.reflect.Parameter objects created by core libraries; return newly created String instances for the names upon demand.

Problem

java.lang.reflect.Parameter instances may retain a lot of duplicate strings representing synthesized names, like "arg0", "arg1", etc. Each synthetic Parameter has its own synthesized names, so there are a lot of duplicate equivalent string objects observable in applications making use of parameter reflection, such as the Spring Framework.

Solution

Remove the eager creation of synthesized names for completely-synthesized parameters. The content of the synthesized names is still identical to before, in the form "arg" + index, where index is the 0-based index of the parameter in the list of all parameters, with no double increment for long or double.

Currently, MethodParameters attribute takes three forms depending on how a Java program is compiled:

• No attribute: For no parameter, or all explicit parameters with no -parameter javac flag
• Attribute with all 0 names: Since JDK-8292275, for any mandated/synthesized parameter with no -parameter javac flag; always fell into the no attribute category before
• Attribute with full name information: Has any parameter, and -parameter javac flag is present

Core reflection only synthesizes Parameter objects for the first no attribute case. In this case, it creates and caches all synthesized names without sharing.

For any 0 name, hotspot creates a Parameter with null name, and the name is only synthesized upon Parameter::getName calls and is never retained. So this != of two obtained synthetic names already exist with some constructors out in the wild since JDK-8292275, and apparently there is no report of incompatibility.

(In fact, back in JDK 8, core reflection had poor handling for this - a bugfix for mishandling 0 names in JDK 9 was not backported until JDK-8341145 arose.)

This solution essentially creates completely-synthesized parameters with all null names, as if they are all 0 named. This allows us to reuse existing routine and resolve the particular phenomenon observed in the original RFE.

Specification

No change. This is completely an implementation detail and is not expected to be relied on, as there is unlikely to have dependency around string identity here.