mapped io for non-default file system

Philippe Marschall philippe.marschall at
Mon Jul 1 00:57:33 PDT 2013

On Wed, Jun 26, 2013 at 8:36 PM, Alan Bateman <Alan.Bateman at> 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?


More information about the nio-dev mailing list