When parsing the manifest file of a JAR file the JDK constructs a java.util.jar.Manifest instance. The Manifest instance consists of java.util.jar.Attributes instances which correspond to the attributes of the manfiest file. An Attributes instance is a name-value mapping and the name is represented by the Attributes$Name class.

Several attribute names that appear in a manifest file are standard names and many of those names may be repeated. For example, when a JAR file is signed (using the jarsigner tool), the each entry in the JAR file will have a digest recorded in the manifest file as an attribute name:

Name: foo.txt
SHA-256-Digest: ...

Name: bar.txt
SHA-256-Digest: ...

Each of these "Name" and "SHA-256-Digest" attribute names thus translate to a Attributes$Name instance, when parsed.

JAR file instances are typically cached by the internal implementation of the JDK and as a result the Manifest instance and the Attributes instance too are cached. Several releases back it was noticed that these Attributes instances can contribute to increased memory footprint of the runtime. In https://bugs.openjdk.org/browse/JDK-6805750 a performance improvement was implemented (RFR https://mail.openjdk.org/pipermail/core-libs-dev/2018-April/052697.html) to maintain an internal cache of some well-known attribtue names mapped to a single instance of Attributes$Name. That way, several occurences of "SHA-256-Digest" attribtue name would end up using a single instance of Attributes$Name for that name. This cache is maintained as a static field in java.util.jar.Attributes class.

Recently, in Java 19, the jarsigner tool was enhanced to use SHA-384 as the default digest algorithm instead of the previous SHA-256 algorithm. That was done in https://bugs.openjdk.org/browse/JDK-8283475. Since then, when jarsigner tool is used to sign the JAR, the manifest file generated in the signed JAR would now have:

Name: foo.txt
SHA-384-Digest: ...

Name: bar.txt
SHA-384-Digest: ...

The internal cache that's maintained in java.util.jar.Attributes doesn't know of this new attribute name so ends up creating separate instances of Attributes$Name for each occurence of the SHA-384-Digest attribute name.

A user reports in core-libs-dev that this now shows up as an increase in the memory footprint of the runtime https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/142299.html.