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.ri...@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. :)
