Morning Eirik, Thank you Sean for creating the CR. As of this week, Eirik has author status so he can now create JBS issues 😊
I believe Jai is going to follow up with you has he started down a similar path earlier this week looking into a jarsigner issue. So please coordinate to avoid duplication. Also, it would probably be worth looking a ZipFS for the same improvement. Thank you again Eirik(and Jai) for looking into this issue Best Lance On Mar 10, 2023, at 5:39 AM, Sean Coffey <sean.cof...@oracle.com<mailto:sean.cof...@oracle.com>> wrote: I think that's a fine idea Eirik. Definitely has its use cases like you mention. Some jarsigner operations would also benefit from this. I've created https://bugs.openjdk.org/browse/JDK-8303960 to track it. regards, Sean. On 31/01/2023 23:41, Lance Andersen wrote: 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. <oracle_sig_logo.gif> 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> [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>
