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

[David M. Lloyd]

My mistake, we're not talking about strings.  Still you can subclass and 
determine whether the buffer size guess was right, and if so return the 
array as-is (swap in an empty array or something as needed).

On 07/19/2013 01:28 PM, David M. Lloyd wrote:
> It's trivial to subclass ByteArrayOutputStream and add a method which
> converts its contents to a string using the two protected fields which
> give you all the info you need to do so.  So no extra copy is needed
> that you aren't already doing.
>
> On 07/19/2013 01:06 PM, roger riggs wrote:
>> Hi Ivan,
>>
>> I think this change takes too big a hit for the cases where the size is
>> correct.
>>
>> No real file system can be wrong about the size of a file so this is a
>> problem
>> only for special file systems. If the problem is with size reporting zero
>> then maybe using the incremental read only for size == would be a better
>> fix.
>>
>> At least you could pass the size to the constructor for BAOS and avoid
>> the thrashing for every re-size; but still it will allocate and create
>> an extra copy
>> of the every time.
>>
>> $.02, Roger
>>
>>
>> On 7/19/2013 1:15 PM, Ivan Gerasimov wrote:
>>> Hello everybody!
>>>
>>> Would you please review a fix for the problem with
>>> j.n.f.Files.readAllBytes() function?
>>> The current implementation relies on FileChannel.size() to preallocate
>>> a buffer for the whole file's content.
>>> However, some special filesystems can report a wrong size.
>>> An example is procfs under Linux, which reports many files under /proc
>>> to be zero sized.
>>>
>>> Thus it is proposed not to rely on the size() and instead continuously
>>> read until EOF.
>>>
>>> The downside is reallocation and copying file content between buffers.
>>> But taking into account that the doc says: "It is not intended for
>>> reading in large files." it should not be a big problem.
>>>
>>> http://bugs.sun.com/view_bug.do?bug_id=8020669
>>> http://cr.openjdk.java.net/~igerasim/8020669/0/webrev/
>>>
>>> The fix is for JDK8. If it is approved, it can be applied to JDK7 as
>>> well.
>>>
>>> Sincerely yours,
>>> Ivan Gerasimov
>>
>
>


-- 
- DML