RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Paul Sandoz paul.sandoz at oracle.com
Thu Oct 15 08:53:01 UTC 2015

> On 15 Oct 2015, at 05:00, Xueming Shen <xueming.shen at oracle.com> wrote:
> I'm not sure if it is a good idea, from performance perspective, to add a "versionEntry" field into the JarEntry
> to support this feature, given most of the jar files might not be multi-release-jar aware, and the Jar input&
> output streams dont work with a multi-release jar directly. Why should they all pay a runtime price for it. If
> we really have to add an extra field, the JarFileEntry might be a better place, and it might be desired to
> define a new subclass JarFileEntryMR to use when the MR is enabled, instead of adding directly into the existing
> JarFileEntry.

According to jol there is currently space available due to alignment. If there was not it would add about 4% in direct instance size. But the actual footprint is likely to be chunkier because of the string character storage for the name so the % increase in size would be smaller e.g. perhaps on average < 2% which might be ok given that i presume such entries are unlikely to be cached.

So i am not concerned about the size. If there was a way to design it to avoid modification of existing classes all the better, but i dunno if it is possible. Steve will surely know more.


More information about the core-libs-dev mailing list