RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory
Alan.Bateman at oracle.com
Mon Jan 28 19:45:26 UTC 2019
On 28/01/2019 18:39, Viswanathan, Sandhya wrote:
> Hi Alan,
> Could you please let us know more on what does it mean to be a jdk-specific feature? How it is to be implemented? An example would be very helpful.
> ByteBuffer is a widely used API and deprecating ByteBuffer any time would make it difficult for more and more Java software frameworks to move up to the latest JDK.
In the API docs, you'll see a number of JDK-specific modules with names
that start with "jdk." instead of "java.". Many of these modules export
JDK-specific APIs. The jdk.attach module exports the JDK-specific
com.sun.tools.attach API. The jdk.management module exports the
com.sun.management API which has defined JDK-specific extensions to the
management API since JDK 5.
Closer to the feature under discussion are APIs that are extensible to
allow for support beyond what the Java SE API specifies. The Direct I/O
feature in JDK 10 defined a JDK-specific OpenOption that you can specify
to FileChannel.open, e.g.:
var channel = FileChannel.open(file, StandardOpenOption.WRITE,
Another example is socket options. Java SE defines "standard" socket
options in java.net.StandardSocketOptions but an implementation can
support many others. The JDK has the jdk.net.ExtendedSocketOption to
define additional socket options so you can do things like this:
Socket s = ...
The suggestion on the table is to see if we can do the same for file
mapping modes so that the platform specific MAP_SYNC mode can be used
with the existing API. This would allow for code like this:
MappedByteBuffer mbb = fc.map(ExtendedMapMode.READ_WRITE_SYNC,
There's plumbing needed to make this work as the underlying
implementation would be in java.base but the platform specific map mode
defined in a JDK-specific module. There are several advantages to the
approach, the main one is that it doesn't commit Java SE to supporting
this mode. I'm hoping to meet up with Andrew Dinn at FOSDEM to discuss
this approach in a bit more detail.
You asked about deprecating ByteBuffer but I don't think there is any
suggestion to do that here. Once Panama is further along, specifically
the memory region or scope/pointer API, then interop with ByteBuffer
will need to be worked out.
More information about the core-libs-dev