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

[Mario Torre]

On Mon, Feb 17, 2020 at 3:39 PM Claes Redestad
<claes.redestad at oracle.com> 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.
>
> 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.

JMC has been made aware of OpenJDK8u+JFR, and although there are still
some issues we're fixing now, it works pretty well.

I don't know other tools that would not work, but it doesn't really
matter. If a tool doesn't recognise JFR in OpenJDK8u it's not
different than now where there is no JFR.

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

How can a common backport that is fully based on the code currently in
11 create fragmentation where in fact there exist an alternative
proprietary JDK with a different JFR plus a variety of downstream
distribution that are shipping with some form of support for JFR? We
aim to cure fragmentation, not make it worse, we don't like
fragmentation.

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

I don't disagree with this, in fact, although I've been working on the
backport I've made my opinion known that I prefer if this isn't
backported, even before the backport started I suggested we shouldn't
do it, but not for the reasons you highlighted. I think the only
reason why JFR may not be desirable is the high complexity of this
patch and the areas it touches, with risks of destabilisation of the
OpenJDK8u. On the other hand, testing done by the aforementioned
downstream distribution seems to suggest this is relatively safe.
Having reviewed most of the patches we are backporting I know there's
subtleties that need to be carefully assessed before we can call it
done, but it's not necessarily something that we don't want, and
speaking with a lot of the players involved has convinced me that it
warrants at least a proper try.

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

Well, yes. And no. The small area it touches is critical and we don't
want to risk to break it either. What I'm getting at is that there is
no proper one size fits all answer, each and every backport needs to
be assessed, what we can do is to define general guidelines where a
backport is desirable and when it's not.

My personal opinion is that all backports should be done very
carefully, in fact, for me we should also limit the number of single
patches backported, let alone features, but not at the risk of
fragmentation of the codebase.

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898