RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

[Peter Levart]

Hi Alan,

On 1/18/19 2:32 PM, Alan Bateman wrote:
> On 17/01/2019 14:27, Andrew Dinn wrote:
>> :
>>> Vladimir and I have reviewed the JEP, it will need an area lead to
>>> endorse, I think it can be Brian or Mikael in this case.
>> Ok, thanks for the above answers. Looking forward to hearing further
>> from Brian and/or Mikael (Vidstedt, I assume? :-).
> I had a brief discussion with Brian about this yesterday. He brought 
> up the same concern about using MBB as it's not the right API for this 
> in the longer term.  So this JEP is very much about a short 
> term/tactical solution as we've already concluded here. This leads to 
> the question as to whether this JEP needs to evolve the standard/Java 
> SE API or not. It's convenient for the implementation of course but we 
> should at least explore doing this as a JDK-specific feature.
>
> To that end, one approach to explore is allowing the FC.map method 
> accept map modes beyond those defined by MapMode. There is precedence 
> for extensibility in this area already, e.g. FC.open allows you to 
> specify options beyond the standard options specified by the method. 
> It would require MapMode to define a protected constructor and would 
> require a bit of plumbing to support MapMode defined in a JDK-specific 
> module but there are examples to point to.

You meant package-private constructor, right? Protected constructor 
would allow subclassing MapMode by arbitrary user class which is not 
what would be desirable. So perhaps all that is needed is to declare the 
static final field in the MapMode class as package-private. That would 
allow referenceing it in the java.nio.channels package. Then add 
SharedSecrets mechanism to expose it's value to other needed java.base 
packages and to the additional module that would expose it publicly...

Regards, Peter