Files.read/readAllBytes can loop once with zero size buffer

[Fabian Lange]

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,  <ecki at 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.fabian at 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
>
>>
>
>