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

[Andrew Haley]

First, let me state that in this discussion I am doing my best to
ensure that I am not biased by my job at Red Hat: despite my signature
below, I am writing as the JDK 11 Updates maintainer. I will try to
remain neutral and act in the best interests of the project, as I hope
will everyone else in this discussion.

On 2/7/20 4:19 PM, Gil Tene wrote:
> I think this is a discussion about the core of what an OpenJDK XXu update
> project is intended to do and produce, and what it's primary directives are.
>
> Let explain my opinion on the subject. Others' opinion will likely differ.

Probably.

> As I see it, the overriding purpose of an OpenJDK XXu project is to
> stabilize and maintain the associated Java SE release implementation
> as it is, with no intent to add any improvements or features. It is
> about applying bug fixes and security updates to a given OpenJDK
> Java version, in order to keep it's current use rock solid. It is
> not about "making it even better:". The place to make things "even
> better" is in upstream versions. We have one of those leaving the
> station every 6 months, with an LTS every three years, and those
> provide plenty of opportunities to bring better-ness to the
> community.

Well, yes, kinda sorta: we must not be foolhardy, because the safety
of our users and the reputation of OpenJDK is at stake.

However, OpenJDK is free software, so another issue at stake is
freedom: we want people to have a choice. Therefore, we should ensure,
as much as we can, that our users are not forced into the arms of
proprietary software vendors because of features lacking in equivalent
OpenJDK releases.

> While it may be tempting to try to improve things under the hood
> (e.g.  by making stuff faster, smaller, or better on some metric) or
> in visible ways (e.g. by adding options, features, etc.) in stable
> or in just-now-released versions, doing so will inherently risk the
> stability of the existing version, and put the main purpose of the
> updates project at risk.

I understand. However, if we can determine that a feature backport is

    a. Desired by a number of downstream distributors (and their
    users), and

    b. Sufficiently guarded by flags (e.g. #ifdef) that we can
    determine statically that a feature has no effect if not
    enabled/configured

... I believe we will not be taking undue risks. Downstream
distributors can take the decision to enable features or not.

You might argue that even when not configured there is some slight
risk, but surely a risk has to be plausible, not just theoretically
possible.

> For things that do not rise above the ""something is missing" bar in
> the main updates project, curation choices about back-porting or
> adding features and improvements to older versions can (and should)
> still be independently made in downstream distributions and projects
> (e.g. Zulu, Corretto , DragonWell RedHat's OpenJDK builds, Liberica,
> AOJ, and even Zing are all examples of downstream distros that make
> such choices every day, and so do e.g.  shenandoah/jdk11).

Certainly, this happens. However, we are at some risk of Balkanization
of JDK 11 distributions, with downstream vendors independently
packaging extensions. This is a Bad Thing and a waste of effort. If we
can share resources without risking our users' stability then everyone
benefits.

> In this specific case, I see a clear and default path within
> OpenJDK: Focus on stabilizing Shenandoah 2.0 in 15u & 16u to the
> point where it is no longer an experimental feature. Getting it into
> 17u LTS (a mere 19 months from now) will be a much more important
> and useful achievement then backporting it into 11u in an
> experimental state.

Here, I think you may have a point: there is a question about whether
experimental features should be back-ported. However, there are
already experimental features in JDK 11, so it's not as if they're
completely verboten in LTS releases. We should decide on the actual
demand (the benefit) versus the actual intrusiveness (the cost) rather
than in-principle arguments which may have more to do with theology
than engineering.

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