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. Another approach is aanother class in a JDK-specific module to define the map method. It would require the same plumbing under the covers but would avoid touch the FC spec.

-Alan

Reply via email to