RFD: JDK-8221477, JDK-8221397, JDK-8221696, JDK-8224974

[Langer, Christoph]

Hi Andrew,

when you're going to backport these items (in a way that is suitable for backporting, e.g. no spec breaking changes, obviously), I would suggest that you tackle each bug one by one. E.g. you can immediately start with JDK-8221477 which to me looks like it could be backported straight away without involving a CSR process. The other 3 items should undergo a CSR review one by one and some adoptions will have to be taken to make sure they don't break the spec, e.g. add new public API methods as private methods...

Best regards
Christoph


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Dinn
> Sent: Donnerstag, 21. November 2019 13:05
> To: Andrew Haley <aph at redhat.com>; Gil Tene <gil at azul.com>
> Cc: Jonathan Halliday <jonathan.halliday at redhat.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: RFD: JDK-8221477, JDK-8221397, JDK-8221696, JDK-8224974
> 
> On 21/11/2019 08:25, Andrew Haley wrote:
> > On 11/19/19 3:51 PM, Gil Tene wrote:
> >> As a rule, any in-version changes to the public Java SE APIs, including
> >> the addition of new methods, are a “don’t do this” sort of thing. In the
> >> extremely rare cases where they are necessary (e.g. security driven)
> >> a rev to the spec (and often to the TCKs) is required.
> >
> > I don't think we need to do that. As I understand it, we can make the
> changes
> > to jdk.internal.misc.Unsafe without breaching anything. We can use these
> > Unsafe methods in an external library, and we can do the mapping itself
> > in a library too.
> Yes, I have had a talk with Jonathan Halliday about this and I believe
> we can ensure that the functionality can be made available via a 3rd
> party library without changing JDSK11 SE at all i.e. without the
> addition of any new modules or packages and without modifying any of the
> public API surface of the JDK11 class base. We can follwo Gil's lead and
> do this via a library that will work on jdk11u and continue to work on
> jdk14+.
> 
> I will prepare a new patch that includes much the same changes to the
> underlying implementation. However, it will make be tweaked to make the
> new FileChannel map and  MappedByteBuffer force behaviours available via
> private methods only (these methods will also be exposed in private
> method handle fields). This mode of proceeding will mean we can omit the
> need for any changes to the public FileChannel MapMode enum.
> 
> Access to this new, fully private functionality will then be provided by
> a non-SE module library. On jdk11u it will need to use Unsafe to access
> the private method handles and employ them to provide a safe public API
> for invoking the required map and force behaviours. Making that work
> will require the user to explicitly export access to Unsafe to the
> library. Obviously on jdk14+ the same library can simply call the
> relevant public APIs directly and the need to export access to Unsafe
> will disappear.
> 
> Regarding Martin's comments, I will be happy to delay this backport
> until the relevant functionality was available in a jdk14 release. I
> understand why he would prefer for the current behaviour to have baked a
> bit longer in jdk14.
> 
> 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