Implement FileSystemProvider.newFileChannel(...) about memory-fs

[robtimus]

I will see what is possible here. The main issue is that FileChannel adds more responsibilities. Some parts are quite easy to do because FileChannel implements SeekableByteChannel which is already supported. The most work will be in adding not just the locking methods, but also the map method.

[robtimus]

I've been investigating this, but I'm not sure it's possible to implement support for FileChannel while still following the official contract. The problem lies with the map method. It must return a MappedByteBuffer, but this class has no available sub classes, and because it has no public or protected constructors it's also impossible to create my own sub class.

I could implement FileChannel minus the map method, but that's where the contract is limiting me - the method itself does not document that I'm allowed to throw an exception. FileSystemProvider even disallows it. From its newFileChannel method documentation:

A provider that does not support all the features required to construct a file channel throws UnsupportedOperationException.

[gadton]

That's really weird! Seems that no one should provide another FileChannel without placing at least one class into one of the java.nio.* packages.
I would think providing FileChannel minus map would be ok as I understand the spec in a different way. I think it means that the provider should throw UOE if it does not support at least one feature regardless if the created channel provides all the features.

[robtimus]

Out of curiosity, I have checked the implementation of jdk.nio.zipfs.ZipFileSystemProvider. This delegates indirectly to jdk.nio.zipfs.ZipFileSystem. This returns a FileChannel which all methods of FileChannel minus map, which throws an UOE. That means that you are probably right - if one of the default implementations can do it, so can other implementations.

[robtimus]

I've just released version 1.2 with FileChannel support minus the map method.