Hi, yes something like that. I have no strong opinion. After discovering this, I switched to a hand rolled implementation with file name depended estimated buffer sizes. But usually inside the JDK, Edge cases are handled better, usually with some Math.min()/Math.max logic.
IMHO that really depends how common it could be that SeekableBytesChannel returns a size of 0 while actually containing data. If the proc files are the only realistic scenario, then maybe my concern is not that valid Fabian On Fri, Jul 29, 2016 at 8:21 AM, <e...@zusammenkunft.net> wrote: > Hello, > > > > It could always read with a initial buffer of 0.5-16k and return a truncated > copy if it read less (and a omit truncation by returning shared static 0 > length array if empty). But this will only optimize the 0 byte case. > > > > > Gruss > Bernd > -- > http://bernd.eckenfels.net > From Win 10 Mobile > > > > Von: Martin Buchholz > Gesendet: Freitag, 29. Juli 2016 03:33 > An: Fabian Lange > Cc: core-libs-dev > Betreff: Re: Files.read/readAllBytes can loop once with zero size buffer > > > > What do you suggest instead? > > > > The extra allocation of a zero-size buffer is not that bad. > > > > I think it's best to optimize for files with correct metadata, while > > tolerating ones with buggy metadata. > > > > On Thu, Jul 28, 2016 at 1:13 PM, Fabian Lange <lange.fab...@gmail.com> > > wrote: > > > >> Hi, > >> I just noticed that when one uses Files.readAllBytes() to read for > >> example from the Linux proc file system, where file size is claimed to > >> be 0, Files.read() will allocate a buffer of size 0 before then > >> adjusting in a second loop (arraycopying the zero size buffer) > >> > >> In my opinion an initial size of 0 should not be used. > >> I admit this might be a regression for files which are really empty > >> and return an empty byte array, but I think it is actually more common > >> to read from files which incorrectly report to be zero sized. > >> > >> Fabian > >> > >
