...

[Gil Tene]

> On Jun 29, 2020, at 2:42 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 28/06/2020 15:22, Gil Tene wrote:
> 
>> We simply don't have necessity behind the suggestion for adding a
>> brand new garbage collector to the upstream 11u distribution. We
>> have people who'd like to see it happen, and people who will agree
>> to deal with he issues that may arise and help fix them in future
>> updates. And we have multiple groups that are willing to run it
>> internally within their large organizations and self-support if
>> needed. But we don't have an external forcing event that says that
>> unless we do this we'll be causing tons of end-users to break or
>> start malfunctioning.
> 
> So Gil, please help me out here. You ship a (very) heavily modified
> JDK11u in the shape of Zing to your customers, do you not?

Yes. And you ship a (very) heavily modified JDK11u in the shape of
the RedHat build of OpenJDK to your customers, with similar
differences. That's why we cooperate here, in the upstream place
where the various downstream distro build and maintain the common
ground.

> So you are
> presumably not opposed to diverging heavily from 11u as a matter of
> principle, and least not in your proprietary releases.

Right. And not in your proprietary ones either.

I'm in no way saying that downstream distros should all be identical to
the upstream (I do often, elsewhere, say that they should be at least
up to date in fixes and security updates for the same reported update
level version, but that's a different matter).

> 
> Perhaps the argument is that the addition of Shenandoah to JDK 11
> might have been appropriate had it happened in the past, but it is not
> appropriate now.

It would absolutely have been appropriate to put it into 11u before the
first 11 GA. Just like it was absolutely appropriate to put into the 12 GA,
and why it is part of 13u, will be part of 15u, and will be in the 17u LTS.

> Why does that make sense? Is it simply that there
> has been more time for things in Zing to bake; but some downstream
> distros have been shipping Shenandoah-ified versions of JDK11u for an
> considerable time now, so it can't be that.

> 
> Or is it that it's OK for downstream distributors of JDK11u to modify
> them heavily, but not JDK11u itself, (presumably) because it has more
> users than any of them?

Sort of, but not because it has more users. It's because it forces all
downstream (and hence ALL users) to do something they are not
choosing, anbd that many of them would not choose if they had a
choice. People choose their downstream distros. But when they
need to run Java 11 code, their choices are pretty the Oracle JDK
or a one of the various downstream-from-OpenJDK-11u distros.
An 11u upstream change is a forced change for all  OpenJDK users.

If C4 [which has been "baking" in production use for nearly a decade] or
other Zing features were added to OpenJDK tomorrow, I would not be
advocating for including them or backporting them to the 8u or 11u upstream
LTS code that every downstream distro syncs up with. It would go into
some future version before the first GA date for that version.

> 
> Or is it that all changes to JDK11u are in-principle bad, regardless
> of their actual risk, which we should not consider?

All feature additions in updates for an already released version (as
opposed to bug fixes and security updates, which those updates
are the vehicle for) are in-principle bad IMO. Sometimes we have to
do the bad thing because it is less bad than the alternative (the LTS
will break for many people if we don't do it). But it is still bad.

> That possibility
> seems a little odd. Given that most of your post is couched in terms
> of risk, to say that we shouldn't strive to evaluate that risk would
> be downright irrational.

The weighing of risk for adding a feature in a new OpenJDK version
should be very different from the weighing of the same in an update
to an existing version.

When we add features to new versions (which we now get to do every
six months), we don't risk regressing production behavior of people
that depend on security updates to keep operating. We then consider
the risk in terms of "will this impact adoption rate or make us look
bad", and the benefits can be weighed against that risk. That's where
the benefits of new features often get to win, and we can choose ways
to minimize risk to help them win.

In contrast, when we consider adding features in an updates for an
existing version (which will be forced on all production users that need
to keep up with security, for example), the benefit of a new (did not
previously exist in that Java version) feature should simply not be part
of the equation unless it meets a base "necessity" requirement.
Without meeting that requirement, it should score a 0 on weight IMO.

Necessity has to do with fixing broken things, or preventing things from
breaking. Not working on some new piece of hardware or a new version
of OSs counts as "breaking" IMO, and security, correctness, and
stability bugs do to. Even some seriously degenerate performance
issues may be (although performance 2+ years into a release should
not be something we should be working on improving within that
release).

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