RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES
stuart.marks at oracle.com
Wed Dec 5 00:52:58 UTC 2018
On 12/4/18 12:32 AM, Claes Redestad wrote:
> These non-standard and tool/library specific names appear in the manifest of a
> great many jar files, for example on maven central, and including the most
> common non-standard manifest attributes significantly reduce allocation churn
> reading such manifests. Especially true for ones that were oft repeated within
> the same manifest, e.g.,"Name" and "SHA1-Digest" for signed entries.
> Was it a crucial optimization? Probably not, a few percent on some startup
> Ideals vs trade-offs... Hard-coding a bunch of arbitrarily chosen external
> values isn't exactly pretty, sure, but I do think the JDK should try to optimize
> for typical behavior, and the fact that many (most?) libraries on maven central
> have OSGi attributes ("Bundle-*") in their manifests is one such typical
> behavior, and this optimization was very low cost and net beneficial on most.
> With 8214712 the overhead cost is even less (almost zero in fact).
It might be worth adding a comment to say that's where these names come from.
That is, they appear to occur frequently "in the wild" but otherwise have no
special significance or meaning in the JDK.
Also, could addName() return a Map.Entry, and then you could just initialize
KNOWN_NAMES using Map.ofEntries(), passing the whole list of entries from the
addName() call? It might be preferable to building an intermediate HashMap.
More information about the core-libs-dev