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