CSR :
|
|
Relates :
|
|
Relates :
|
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. 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. (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.