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