RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

Chris Hegarty chris.hegarty at oracle.com
Thu Oct 15 21:21:33 UTC 2015

> On 15 Oct 2015, at 21:59, ecki at zusammenkunft.net wrote:
> Hello,
> This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would ignore them, the  old version was consuming then and then fail the check. However I am not sure if this is relevant.

Right, there are certainly some subtle differences resulting from
the proposed change. When working on JDK-8138978 I thought
about using readNBytes, but played it safe as IOUtils was growing
the bye[] lazily too, so no real perf difference.  In fact, I think I seen
a test failure with using readNBytes here. I’ll have to check.


> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> -----Original Message-----
> From: Claes Redestad <claes.redestad at oracle.com>
> To: "core-libs-dev at openjdk.java.net Libs" <core-libs-dev at openjdk.java.net>
> Sent: Do., 15 Okt. 2015 22:43
> Subject: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes
> Hi all,
> java.util.jar.JarFile could be improved further by using 
> InputStream.readNBytes when there's information in the ZipEntry about 
> the entry size.
> Webrev: http://cr.openjdk.java.net/~redestad/8139706/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8139706
> Testing: verified improvements in internal startup/footprint tests
> /Claes

More information about the core-libs-dev mailing list