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
