RFR  java.nio.file.Files.readAllBytes() does not read any data when Files.size() is 0
David M. Lloyd
david.lloyd at redhat.com
Fri Jul 19 18:28:14 UTC 2013
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
> No real file system can be wrong about the size of a file so this is a
> 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
> 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.
>> The fix is for JDK8. If it is approved, it can be applied to JDK7 as
>> Sincerely yours,
>> Ivan Gerasimov
More information about the core-libs-dev