On 14/04/2020 09:59, Eirik Bjørsnøs wrote:
On Tue, Apr 14, 2020 at 10:15 AM Alan Bateman <alan.bate...@oracle.com
<mailto:alan.bate...@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.
