mapped io for non-default file system

[Remi Forax]

On 06/26/2013 08:12 PM, 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).

I believe it's intentional, in order to avoid a dynamic dispatch
(or at least some class checks) when doing a get or a put (which will be 
a real perf killer),
all NIO buffers inherits from MappedByteBuffer and not the opposite.
It's not pretty, but you can not let users to freely subclass 
MappedByteBuffer because of that.

>
> Cheers
> Philippe

cheers,
Rémi