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.
Best Regards, Sandhya -----Original Message----- From: Alan Bateman [mailto:alan.bate...@oracle.com] Sent: Friday, January 18, 2019 5:33 AM To: Andrew Dinn <ad...@redhat.com>; Brian Goetz <brian.go...@oracle.com> Cc: core-libs-dev@openjdk.java.net; hotspot compiler <hotspot-compiler-...@openjdk.java.net>; Jonathan Halliday <jonathan.halli...@redhat.com>; Viswanathan, Sandhya <sandhya.viswanat...@intel.com> Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory 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
