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

[Andrew Dinn]

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'?

> 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?

> 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. 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