Two issues in Files

[Colin Decker]

On Thu, Sep 12, 2013 at 4:30 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> On 11/09/2013 22:36, Colin Decker wrote:
>
>> Hi,
>> I noticed a couple of small issues in Files for JDK8.
>>
>> The first, more significant issue, is that Files.readAllBytes(Path) now
>> creates a FileChannel, while FileSystemProvider implementations are not
>> required to support FileChannel. A SeekableByteChannel could be created
>> instead, and at least seems much more likely to be supported than
>> FileChannel.
>>
> I'll create a bug for this, it should be using newSeekableChannel and then
> testing if it is a FileChannel before deciding how to get the size.


Thanks. Since SeekableByteChannel has the size() method, it shouldn't even
be necessary to check if it's a FileChannel I think.


>
>
>
>> The second issue is with Files.write(Path, byte[], OpenOption...).
>> Instead of passing the whole input byte array to
>> OutputStream.write(byte[]), thus allowing the OutputStream implementation
>> to decide how best to handle it, it loops through writing 8k slices of the
>> array to the OutputStream. Is this intended? It seems wasteful,
>> particularly if an implementation (such as an in-memory implementation)
>> could just write the whole array at once (and might even benefit from
>> knowing up front the total number of bytes being written.)
>>
>>  I don't know if there is a right answer to this one. If the underlying
> write requires using an intermediate buffer outside of the heap (common
> case for the default file system when the VM doesn't support any means to
> pin byte[] in the heap) then writing the entire array might be undesirable.
> So the slicing was intentional although there 8k might be a bit small.


As I see it, if something like that is needed, it seems like the
OutputStream implementation should be doing the slicing. Giving the whole
array to the OutputStream gives it the best opportunity to do what works
best for the implementation.


>
>
> -Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130912/232528b9/attachment.html