...

[Mario Torre]

On Wed, Jul 1, 2020 at 2:08 AM Claes Redestad <claes.redestad at oracle.com> wrote:

> This huge risk, and the fragmentation it brings with it, IMHO means that
> the JFR backport should have been considered unacceptable for 8u LTS.
> Still should be. That's the only thing I think Gil is slightly wrong
> about in this discussion.

JFR in 8u was a [calculated] risk because of the level of changes and
this is why it took almost one year, and it's still not really
finished. But there's no fragmentation or incompatibility with Oracle
JDK because the recordings can be read by the same tools and it
doesn't matter what JDK produces them. There's no specification for
the recording format on purpose but you have tools and they are
available to all and they work with all the different flavours. The
additional API that was introduced isn't used by legacy code that runs
on 8u, so all existing code works as it did before. If anything, it
offers a new migration path now. Everyone wins big time now.

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

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