...

[Gil Tene]

>> On Jul 2, 2020, at 3:00 AM, Mario Torre <neugens at redhat.com> wrote:
> ...
> In general, I think we need to get over the mentality that it's ok to
> have downstream distributions of jdk8u differentiated by some key (or
> perceived key) features, perhaps closed and only available from one
> vendor. Historically, that is what has happened with jdk8u though and
> we now have to deal with the consequences. JFR support was developed
> in Oracle’s proprietary downstream of jdk8 and also added by Ali Baba
> and Azul to their proprietary releases. Shenandoah was developed in
> Red Hat’s downstream of jdk8 and only made its way upstream in a later
> release. Several other features were added in other vendor’s releases.
> 
> Of course, features should be developed upstream first and there ought
> to be no desire to backport but because of history jdk8u /is/ now
> still feature-fragmented, with Shenandoah the main outstanding feature
> that still exists downstream. There is a gain as well as a risk from
> integrating downstream features, like JFR or Shenandoah, that make
> sense for a significant number of users, into the upstream jdk8u tree
> because this feature-fragmentation runs the risk of introducing more
> bugs and more variation in behaviour. This is what fragmentation
> means, and I'm glad Oracle was aware of this when you released JFR and
> other proprietary features into upstream OpenJDK, that was a huge
> achievement.
> 
> OpenJDK is too important and cannot be an "open core" development
> model, and if some vendors still want to think this can be the case,
> they can't really complain about people stepping in and fixing the
> void. This is true for all projects that have a somewhat critical
> mass, btw, but OpenJDK is clearly the centerpiece of the industry
> today, we must protect it at all costs.
> 
> I can understand that something isn't accepted on a technical ground,
> and not everything makes sense to have upstream, but we must be able
> to discuss and accept changes on something other than a purely
> theoretical perspective, otherwise we will always have the risk of a
> conflict of interest laying in the "niet"; for example, a downstream
> proprietary distribution with a special GC that covers the same areas
> as Shenandoah or a downstream implementation that offers a proprietary
> port of a Serviceability API etc...

Mario, it is pretty rich for an IBM / Red Hat employee to be (repeatedly)
using this nefarious “conflict of interest” argument to question the
motivation of people rather than arguing on the technical merits.

Please stop.

Zulu and DragonWell are no more proprietary than Red Hat’s builds
of OpenJDK. Neither are Corretto, SapMachine, Liberica, and any
other distro that uses the upstream OpenJDK projects (tip, feature
releases, and update projects) as a place to come together, contribute,
coordinate, align on common denominators, and share our work for good.
The good people working on those distributions use the updates projects,
specifically, to coordinate a common denominator for the long term
maintenance of stable versions, including shared bug fixes and security
updates in an upstream, with 11u being one such updates project location.
People working on every one of the above named distros contribute
actual code to the common updates projects. All in all, I’d say this
coordination has been going pretty pretty well, and that it has managed
to resist the commercial Interests of individual companies that project
members happen to work for, or of the distros they work on in their
day jobs, from seeking to shut out or invalidate the participation others
or their distros.

Last I looked, Red Hat has a common, long standing (and in no
way nefarious) practice of adding custom and special features to their
downstream, trademarked distributions of OSS software. These include 
special versions of Linux kernels 2.6.32 (RHEL 6.x), 3.10 (RHEL 7.x),
and 4.18 (RHEL 8.x). It obviously includes the Red Hat builds of OpenJDK,
which differ from the upstream in pretty significant ways (more so than
most other distros listed above). I’m sure you don’t mean to be arguing
that this is “fragmentation” only when it is done by companies that are
not your employer, or by distros other than the one you yourself work on.
And I know you won’t find me claiming that repeatedly on this list.

There are millions of production, non-RHEL users of Linux distros that
did not include Red Hat special modifications to e.g. the 2.6.32 kernels
(e.g. THP, included in RHEL6.x) or 3.10 kernels (e.g. memfd, included in
RHEL 7.x). The features did appear on later-version upstream kernel.org
kernels, but I assume nobody was arguing for forcing all non-RHEL
production users of 2.6.32 or 3.10 kernels (or other stable kernels) to
accept the inclusion of those new features with their security updates.

Similarly, there are millions of production, non-Red-Hat-builds-of-OpenJDK
users of OpenJDK 11u and 8u distros where Shenandoah does not exist,
and neither do various other Red Hat distro-special changes. Similarly,
Shenandoah as a feature is already in the later upstream OpenJDK versions
(12, 13u, 14u), and is therefore part of downstream distros of those later
versions. What we are discussing here is whether the existing users of all
other 11u distros should be forced to accept it as a change with their
coming security updates.

Some users of some distros (including e.g. massive users of Zulu, like
Microsoft, and of Corretto, like Amazon) are saying that they are fine with it,
will welcome it (even if it came in an 11.0.9 update for example) and would
make good use if it. Some users (including other massive users of Zulu, and
of other distos) are saying the exact opposite, noting that they are already in
production with e.g. 11.0.7 on stable, non-continuously-changing applications
and services, will need 11.0.8, 11.0.9, ... for security updates, but
would absolutely not want to see any features added in any latter 11.0.x
LTS updates.

For an updates project, this is what technical (and not at all theoretical)
perspectives look like.

A choice will need to be made for 11u. And it’s not a hard choice. It may be
an annoying choice, and an example where the right choice is not to do that
thing we really want to do. But such is life. To me, the choice seems
obvious in an LTS updates project. We don’t have to like it.

> So far in this discussion I've not really heard any actual technical
> merit, which is what I expected to be discussed instead.
> 
> 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