On 20/07/18 15:05, Alan Bateman wrote:
> On 20/07/2018 14:50, Andrew Dinn wrote:
>> I have finally managed to draft a JEP to formally present the proposal I
>> circulated a month or two back regarding support for MappedByteBuffer
>> access to non-volatile memory.
>>
>> JEP JIRA:
>> https://bugs.openjdk.java.net/browse/JDK-8207851
>>
>> The JEP references a re-implementation of the proposed API:
>>
>> http://cr.openjdk.java.net/~adinn/pmem/webrev.01/
>>
> The JEP proposes adding a map_persistent method to FileChannel. An
> alternative may be to just add new MapModes that you can specify to the
> existing map method. It would reduce the API surface and I think fit
> better with the existing API.
Doh! that's a good idea (I wish I had thought of that :-)
I'll admit that it looks a tad counter-intuitive to specify the storage
characteristics of the data as part the access mode e.g.
class MapMode {
public static final MapMode READ_ONLY = ...
public static final MapMode READ_WRITE = ...
public static final MapMode PRIVATE = ...
public static final MapMode READ_ONLY_PERSISTENT = ...
public static final MapMode READ_WRITE_PERSISTENT = ...
. . .
}
However, it would make the API a damn sight neater.
Also, there is still the question as to whether existing FileChannel
implementations would correctly reject these new modes if passed them i.e.
if (mode == MapMode.READ_ONLY) {
...
} else if (mode == MapMode.READ_WRITE) {
...
} else {
...
}
Thoughts?
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
