> On 15 Oct 2015, at 21:59, e...@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. -Chris. > Gruss > Bernd > > -- > http://bernd.eckenfels.net > > -----Original Message----- > From: Claes Redestad <claes.redes...@oracle.com> > To: "core-libs-dev@openjdk.java.net Libs" <core-libs-dev@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
