JarFile.getVersionedEntry scalability with new release cadence

Alan Bateman Alan.Bateman at oracle.com
Sun Apr 19 14:42:44 UTC 2020


On 14/04/2020 09:59, Eirik Bjørsnøs wrote:
> On Tue, Apr 14, 2020 at 10:15 AM Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>     One thing that I'm concerned about is that
>     META-INF/* is a JAR file concepts and I'd prefer not build up further
>     shared secrets that operate on ZipFile (should be consistent
>     JarFile and
>     JarEntry when dealing with JAR files).
>
>
> True. META-INF/ semantically belongs in JarFile. The reasons for 
> moving the parsing logic to ZipFile.Source were:
>
> 1: Scanning of META-INF/ entries already happens there and scanning 
> META-INF/versions/ is tightly related to this (it's a sub-problem).
> 2: Acceptable performance requires that we keep parsing on the byte[] 
> level, without String conversions. The CEN isn't directly available in 
> binary from from JarFile.
>
My concern was getMetaInfVersions taking a ZipFile when it should be a 
JarFile. Claes addressed this before the change was pushed.

-Alan.


More information about the core-libs-dev mailing list