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

[Volker Simonis]

Claes Redestad <claes.redestad at oracle.com> schrieb am Mo., 17. Feb. 2020,
16:42:

>
>
> On 2020-02-17 16:15, Mario Torre wrote:
> > 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.
>
> Anecdotally I've written tools to extract data from JFR recordings
> using the JMC APIs.
>
> Sure, such tools *should* work transparently by upgrading to the latest
> JMC, but there might be any number of such surprises where tools need to
> be altered/updated that is hard to foresee.
>
> >
> >> 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.
>
> 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...
>
> 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.
>
> On JDK11+ there is no subtle difference in behavior: if you want
> something that is interchangeable with proprietary/commercial offerings,
> it already exists!
>
> >
> >> 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.
>
> 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
>

This is a little bit like asking Oracle to take back the extension to JDK8U
support it has just announced and move its customers to 11+ ;-)


> /Claes
>