RFR [8020669] java.nio.file.Files.readAllBytes() does not read any data when Files.size() is 0

roger riggs roger.riggs at oracle.com
Mon Jul 22 17:16:19 UTC 2013


Hi,

All I was thinking was:

     if (size == 0) {
        use BAOS... code from 1st webrev.
     } else {
         current code
     }

But I am curious why fixing the size() method is not a better fix; if 
FileChannel
can return incorrect values that seems like a more serious flaw in the 
implementation.
And it will contaminate code that uses it with the uncertainty about the 
true size.

Roger

On 7/22/2013 12:50 PM, David M. Lloyd wrote:
> On 07/22/2013 11:19 AM, Martin Buchholz wrote:
>> On Mon, Jul 22, 2013 at 9:03 AM, roger riggs <roger.riggs at oracle.com> 
>> wrote:
>>
>>> Hi Ivan,
>>>
>>> I'm concerned about the change in behavior for the existing working 
>>> cases.
>>>
>>> How many times are the bytes copied in your proposed implementation?
>>> How many arrays are allocated and discarded?
>>> Files.copy()  uses an extra array for the copies.
>>>
>>> BAOS should only be used for size == 0; that would address the issue
>>> without changing the current behavior or allocations.
>>
>>
>> I also think we can do better, but we have to write the low-level code
>> ourselves.
>> copy creates an 8k buffer, which should be unnecessary.
>> I think we can write correct code that treats the file size as purely a
>> hint (or the file size may be changing concurrently), but does no extra
>> allocation in the case where the hint is correct.
>> You can detect end of file using InputStream.read(), but be prepared to
>> handle the returned byte if there's unexpectedly more data.
>> You probably have to special-case size 0, else the return from buffer 
>> read
>> will be ambiguous 0.
>
> It should be very simple; frankly I'm surprised that there has been 
> this much discussion around it. :)




More information about the core-libs-dev mailing list