mapped io for non-default file system

[Philippe Marschall]

On Wed, Jun 26, 2013 at 8:36 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 26/06/2013 19:12, Philippe Marschall wrote:
>>
>> Hi
>>
>> Currently it's not possible for a non-default file system to provide
>> mapped io. A custom FileSystemProvider can override #newFileChannel
>> and return a custom FileChannel. This channel class has to implement
>> #map (since it's abstract in FileChannel) and return a
>> MappedByteBuffer. However even though MappedByteBuffer is abstract it
>> can not be implemented by custom file systems because the constructors
>> are package protected and it has final methods that call native
>> methods (and require a FileDescriptor).
>>
>> So my question is whether this is intentional because the semantics
>> are supposed to be mmap() or rather an oversight. If it's intentional
>> then maybe a comment on FileChannel#map would be helpful to document
>> the expected behaviour for non-defaulft file systems
>> (UnsupportedOperationException or IOException).
>>
>> Cheers
>> Philippe
>
> FileSystemProvider's newFileChannel method is specified to throw UOE when
> the provider does not support file channels and only the default provider is
> required to support file channels.
>
> So the intention is that if a provider supports FileChannels then it should
> implement it completely. I don't think the issue of FileChannels not support
> map has come up before.

Ok, very well. What about AsynchronousFileChannel then? It's the only
way to do asynchronous file IO and offers the same functionality as
FileChannel except for #map (although in an asynchronous fashion). So
unlike FileChannel it can be implemented fully by non-default file
systems. Is the idea that non-default file systems can implement
AsynchronousFileChannel but not FileChannel (because they can't
implement #map) or should they implement neither?

Cheers
Philippe