JDK-8362626 : Avoid caching synthesized names in synthesized parameters
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Priority: P4
  • Status: Proposed
  • Resolution: Unresolved
  • Fix Versions: 26
  • Submitted: 2025-07-18
  • Updated: 2025-07-18
Related Reports
CSR :  
Relates :  
Relates :  
Description
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.