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

[Gil Tene]

> On Nov 19, 2019, at 9:32 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> Hi Gil,
> 
> Thanks for looking at this proposal.
> 
> On 19/11/2019 15:51, Gil Tene wrote:
>> IMO at least some of the the API changes below involve spec-breaking
>> changes to Java SE 11. Such changes only belong in new versions of
>> Java SE that can actually include them in their specification.
> 
> Can you explain what you think are the 'spec-breaking changes'?

The spec covers the entirety of the API, additions to the namespaces
are spec breaking.

The philosophy behind this has served Java well for over 20 years. All
implementations of a Java SE spec version are expected to include the same
no more, no less) APIs in all the spec'ed namespaces. Use of non-spec'ed
namespaces is strongly discouraged if one expects any form of longevity
or compatibility, and should be expected to potentially cause versions-to-version
os-to-os, and and implementation-to-implementation, problems.

> 
>> 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.
> 
> With the proposed patch I have explicitly avoided including public
> method MappedByteBuffer.force(int,int) that was in java.base. That is
> the only new public API method that was added to jdk14 by the original
> patch.
> 
> However, I have backported the new (to jdk14) module and
> java.nio.mapmode and package of the same name. This package backports
> the ExtendedMapMode enum and in the proposed patch I supplemented that
> enum with a new class and a new API method to expose the force API. That
> does not change the behaviour or signature of any existing class. Is
> that still what you consider to be a breaking change?
> 
> I could easily relocate these to a new module and package outside of the
> java namespace. That would cause a slightly stronger dissonance for any
> client library wanting to use the jdk11 and jdk14 APIs but libraries
> could still work around that issue. Would this alternative meet your
> objections?

Moving this outside of the java and java-related namespaces can be
acceptable. In *addition* to that, I prefer to warp the actual use of things
like that with outside-of-the-jdk (and outside of openjdk) commons/public
libraries that deal with cross-Java-version compatibility (i.e. present a
common, theoretically long lasting API to users, and under the hood
choose the right JDK-version-specific way to implement those APIs depending
on the actual jdk version the code finds itself running on).

you can see an example of this "in the small" here:
https://github.com/real-logic/agrona/tree/master/agrona/src/main/java/org/agrona/hints

Where people who were looking to future-proof their spin-knowledgable
code to work well in Java 9+ but also wanted that same code to run
on Java 8 now have a single API that will work across all JDK 7+ versions.
That stuff seems to work ok for "hints" (optional behavior where a noop is a
valid implementation), but *may* also work for wider cases (that's what
commons libraries are, basically).

This sort of thing belongs outside of all JDK versions IMO, but can be
made to work with a specific implementation's exposed APIs (outside
of the java namespaces) using reflective tricks.

> 
>> If the need is critical enough, we can look at providing alternative
>> means for doing these things in 11 via new APIs outside of the name
>> spaces controlled by the java SE specification, e.g. create a new
>> org.nvmmaps.MappedByteBuffer, add intrinsic support for it
>> in OpenJDK 11, and make sure (via reflection or MethodHandles) thst
>> it uses the new features in 14+ when they show up. But that is A
>> bigger undertaking.
> 
> That is a much bigger undertaking but, more importantly, it fails to
> provide for libraries that would like to work with either an
> NVRAM-backed or a volatile-RAM backed MappedByteBuffer.

Alas, presenting people with new capabilities in an existing, locked down
version of the platform probably has to involve replicating the APIs of
existing capabilities in a new "common" namespace. Most of those can
be pass-through APIs, but IMO to present a coherent view of being able to
do both, the end users will have to use an aapi other than the Java SE 11's
existing spec'ed ones.

> That would
> require re-implementing a much larger subset of the code base for most
> existing client applications that could profit from the new API. Since
> this API is intended to allow existing legacy clients that employ
> MappedByteBuffer to benefit from the performance gains offered by the
> availability of NVRAM that rather defeats the purpose of providing the
> library in the first place.
> 
>> I think this is a case where people will just have to wait for a java
>> version that includes them to be released; 14 for those willing to
>> keep up, or later for those that are looking for longer term continuity.
> That is one option. However, I'd much prefer to make access to this
> technology available as soon as possible to avoid the situation where
> Java is left behind as a vehicle for implementing apps that will benefit
> from using NVRAM. We know already that existing Java software can
> benefit significantly from use of NVRAM (we have seen this with Red
> Hat's Transactions, Messaging and Data Grid products). We also know that
> apps writtenin other languages, most notably C, will soon be seeing
> those benefits realized. So, I am unhappy about the idea of waiting and
> would prefer to find a way to make it available now.
> 
> 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