I have not add a chance to look or think about this yet but wanted to know I will
On Jan 19, 2023, at 2:03 PM, Eirik Bjørsnøs <eir...@gmail.com<mailto:eir...@gmail.com>> wrote: Hi, A common use case for java.util.zip in build tools involves copying entries from a ZipFile or ZipInputStream to a ZipOutputStream without actually modifying the data. Example use cases include minification (make a JAR with only the reachable classes) and merging (combine several JAR files into one uberjar). Inflating an entry just to immediately deflate it again with no modifications seems wasteful. The following draft PR introduces ZipFileInflaterInputStream.transferTo which copies compressed ZipFile data directly to ZipOutputStream's raw data stream: https://github.com/openjdk/jdk/pull/12099 I'm typically seeing a 15 X improvement when copying xalan.jar to a ZipOutputStream backed by a buffered FileOutputStream, or 22 X when backed by OutputStream.nullOutputStream(). The PR current stays completely on the happy path and is mostly there to experiment and to show the potential performance benefits. There is currently not much focus on validation or correctness. Copying files to a different path is not supported, neither is copying from a ZipInputStream. I initially considered creating new methods for raw copies, but opted to minimize changes to public APIs, that's why I'm overriding transferTo. The PR is not intended for regular review, but as a starting point for a discussion about the usefulness of the idea and the general solution space. If we can reach consensus on such a discussion, I'll probably be happy to work on a more complete PR. Cheers, Eirik. [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home] Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com<mailto:lance.ander...@oracle.com>
