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
