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
applications.
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.
s'marks
