On 18/01/2019 14:28, Peter Levart wrote:
...unless you actually want users to construct their own MapMode(s),
like you mentioned is the case with FileChannel.open() and
FileAttribute interface. But there this makes sense because the
backend (FileSystem) is also pluggable, so users can define their own
FileSystem implementations that consume their own FileAttribute(s)...
Are you proposing to add an spi for MappedByteBuffer's here? That
would be an overkill for this feature, I think...
No, we definitely don't want to go there as buffers are closed
abstraction. Instead, this is just about allowing the JDK to support
additional map modes beyond those specified by FileChannel.map. If you
create your own MapMode and call the map method with it then it will be
rejected, probably UOE. With the suggestion, a JDK-specific module would
define READ_WRITE_SYNC and you could pass that mode to FileChannel.map.
There's a bit of plumbing needed make that work but there are examples
of this already (e.g. socket options and file open options).
-Alan.
