Backporting features [was Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u]

[Andrew Dinn]

On 17/02/2020 15:45, Claes Redestad wrote:
> The fragmentation I primarily had in mind is that rather than one JFR
> variant there will now be (at least) two different implementations of
> JFR in various versions of 8u which have any number of subtle
> differences in behavior (different set of events, different default
> settings, etc.). There might also be OpenJDK distros that opt-out of
> building with JFR due concerns about stability, performance, etc...

I'd suggest that the first and second of those two cases are different
in degree if not kind. Not doing something is substantially less
difficult to accommodate than doing what purports to be the same thing
in an incompatible way.

> There is also a more insidious difference in that the backport means the
> code for OpenJDK 8u takes a big step away from the state of the fork of
> OpenJDK 8u Oracle maintains for Oracle JDK 8u. This is of course
> something the OpenJDK updates project is free to ignore, but it
> significantly increases risk that critical bug fixes to Oracle's
> proprietary fork will not be applicable to OpenJDK 8u and vice versa,
> which will lead to more work for everyone, and increase risk that
> serious bugs slip through.

Hmm, I'm not very much swayed by that argument. At the very least I
don't really respect its premise. How can I bets put this? The OpenJDK
project didn't exactly create the space within which such divergence has
become possible.

In consequence, I don't think the weight of responsibility for any
further divergence should be placed entirely, or even to a large degree,
on the shoulders of the OpenJDK project. It was Oracle that made a
choice to pursue a different path to all the other parties involved.

As regards the potential consequences of living in such a divided space,
of course we don't want to introduce incompatibility willy-nilly.
However, it is important to bear in mind that the motive for doing so
wrt this and other features (e.g. AArch64 or Shenandoah) is to have one
common version in upstream jdk8u rather than having different versions
in one or more downstream repos (well, one version modulo Oracle's
departure into its own different universe).

Such divergence is a present fact given that Alibaba already have a JFR
jdk8u, Linux distros have an AArch64 jdk8u, Red Hat has a Shenandoah
jdk8u. So, what we are doing here is fixing an existing fragmentation
within the scope of the OpenJDK project.

When it comes to assessing the merits of the proposed jdk8u JFR, I
balance the benefits of that /intra-project/ remedy quite highly
relative to any concern I might have about the potential for
/extra-project/ deviations from Oracle's proprietary version. Indeed,
it's the same story as regards other intra- vs extra-project differences
whether they relate to the AArch64 port, the inclusion of Shenandoah or
evcen differences that emerge in the behaviour of the OpenJDK runtime
itself -- noting of course that the TCK signifcantly limits the scope
for the latter category of divergences to significantly impact users.

I am also, if not exactly underwhelmed, then certainly less than whelmed
by the security story. The backport project has a lot of experience
applying upstream patches that don't directly apply or even, where
needed, developing its own patches. The critical element in managing
such issues has not been down to being handed corrected code by Oracle
but being party to the details of the CVEs that need fixing. Given that
we now do have access to such information I don't see security concerns
as posing such a great threat.

Also, I have to note that if the room for novel security challenges is
such a concern then I do wonder how Oracle can square that concern with
a blithe view of the divergence their decision to pursue their own jdk8u
implies? likewise with their decision to release, over many years, a
version of jdk8u that included JFR when other releases did not.

> Perhaps a bitter pill to swallow, but I think the players involved need
> to take the steps necessary to upgrade to 11+ and stop demanding
> backports that risk destabilizing 8u
I am more sympathetic to that exhortation wrt JFR. Less so wrt aarch64
or Shenandoah. However, many others in the project and, most
importantly, many of our users -- especially those who are going to be
maintaining deployments running on jdk8u for a long time -- feel
otherwise. By not providing those users with a standard jdk8u complete
with JFR we are leaving the open project short of a capability that many
users really need and so failing in our duty to make open source Java a
real alternative to proprietary Java.

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