8132734: java.util.jar.* changes to support multi-release jar files (original) (raw)

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.

Paul.

More information about the core-libs-dev mailing list