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

[Claes Redestad]

On 2020-02-14 15:56, Andrew Haley wrote:
> With regard to the TLS 1.3 and JFR backports to 8u, unless there is a
> substantial risk we must do these because some proprietary Javas have
> them and our mission is to make sure that our end users have the
> choice of using free software. We don't want our users to be forced
> into using proprietary software because our releases are missing some
> important features. For that reason, although these backports are more
> risky than Shenandoah would be, there is a broad consensus in favour
> of them.

Except that the OpenJDK 11 implementation of JFR being backported to 8u
is in fact not perfectly compatible with JFR as it exists in Oracle JDK
8. Apart from JFR in 11 being a major rewrite of the proprietary version
in 8, the set of events is substantially different and the
implementation in 11 relied on strong encapsulation to be correct and
secure.

The JFR in OpenJDK 11 is of course backwards compatible with Oracle's
JFR 8, but tools built to deal with Oracle's JFR 8 are likely to not be
compatible with the JFR being backported to OpenJDK 8u.

So rather merely providing a plug-and-play free software alternative to
a proprietary solution - which I think is in our common interest going
forward - this backport is creating something new entirely that *will*
contribute to fragmenting the JDK landscape. And this with a feature
that is free software in OpenJDK from 11 and onwards.

My personal opinion is that JFR should NOT be backported to 8u.

TLS 1.3 is a different matter altogether, and also a much less risky
proposition since it doesn't touch everything.

/Claes