Use mocks to provide MappedByteBuffers.

[ogregoire]

When called, FileChannel.map throws an UnsupportedOperationException, but the Javadoc doesn't mention any such Exception:

Example code to reproduce the error:

FileSystem fs = Jimfs.newFileSystem();
Path file = fs.getPath("MyFile.data");
FileChannel channel = FileChannel.open(file, READ, WRITE, CREATE, DSYNC);
MappedByteBuffer buffer = channel.map(READ_WRITE, 0L, 1024L);

Okay, I read the code of the method, which is relatively simple:

  @Override
  public MappedByteBuffer map(MapMode mode, long position, long size) throws IOException {
    // would like this to pretend to work, but can't create an implementation of MappedByteBuffer
    // well, a direct buffer could be cast to MappedByteBuffer, but it couldn't work in general
    throw new UnsupportedOperationException();
}

However, I have to say that I successfully mocked MappedByteBuffer using Mockito (latest version). Wouldn't it be possible to create such a mock (using either Mockito or your own bytecode manipulator) so that we can properly test our usage of FileChannel.map?

[mikehearn]

The issue here is the final methods in MappedByteBuffer, right? If so I wonder if a JDK spec change is the way to go here also.

[lukehutch]

I posted a query on nio-dev about this:

https://mail.openjdk.java.net/pipermail/nio-dev/2020-April/007226.html

The issue here is the final methods in MappedByteBuffer, right? If so I wonder if a JDK spec change is the way to go here also.

Actually it appears that the reason the UnsupportedOperationException is thrown is that ByteBuffer has non-public constructors, so cannot be extended.

In theory, Jimfs could add very high-speed copy-free access to in-memory file content if ByteBuffer could be extended. MappedByteBuffer is not needed, Jimfs could just implement its own ByteBuffer subclass, if it could. It's not even possible to mmap a block of memory that is already in RAM, it just needs to be wrapped in a ByteBuffer, so MappedByteBuffer doesn't apply here.

FileChannel does not have an API for directly accessing the content of a file channel as a ByteBuffer, other than by calling map to mmap the file channel. But JimfsFileChannel could just define and return an instance of its own ByteBuffer implementation in response to a call to map, if ByteBuffer could be extended (which it can't be).