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

[Andrew Haley]

On 2/17/20 2:42 PM, Claes Redestad wrote:
> 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.

I hear what you're saying. Of course, any more information that you
can provide will be gratefully welcomed.

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

We'll test with whatever tools we can, of course, and we'll try to fix
any incompatibilities. But as Mario said, this is really about JMC,
and everything else is a bonus.

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

I very strongly disagree. The greatest fragmentation is surely a
*completely missing* JFR implementation in 8u.

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

OK, noted. I thank you for speaking up here, and I'll seriously weigh
your opinion when deciding what to do next.

We must be extremely careful not to break anything, and if in the
final analysis committing the backport looks risky, we won't do
it. The decision is not final and will not be final until the commit
is approved.

But as Andrew Dinn noted, we have a duty to extend freedom, and we
do that best by making OpenJDK8u as compelling a proposition as it can
be. While, yeah, not breaking anything.  :-)

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671