...

[Claes Redestad]

On 2020-07-02 11:59, Mario Torre wrote:
> 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.

First off: everything here is my personal opinions.

There already *was* a migration path: upgrade to OpenJDK 11u.

And no, just because the formats of the recordings are compatible
(modulo the namespace of events), that doesn't mean that the features
are interchangeable. That events have the same performance 
characteristics. That events are triggered for the same things. Etc.
JFR cuts much deeper, and every analysis I've seen of the compatibility
only goes skin deep, since you need access to the closed code to fully
see the difference.

I will always view the JFR backport as an unhealthy catering to the
wants of users, not to what was ultimately best for them (and the
ecosystem). No, it never was a necessity for 8u, unless necessity is
defined as the "necessity to migrate off vendor x", which is a pretty
shitty take to make by anyone in a community of users, developers *and*
vendors.

Either way Oracle is fully committed to supporting and maintaining JFR
in the open in 11u and onwards (to the extent our backports are visible
for the jdk-updates project - but that's another battle..)

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

Sure! And while Oracle's 8u is very "differentiated", it's also an
artifact of history. We've since 11u committed fully to develop all
features in the open and maintain/develop them in the open. Both since
that saves time and resources, but also because it makes good business
sense.

What vendors do with open sourced features in their own private
forks/repos is however (fortunately?) entirely up to them. We can only
appeal to the moral argument that backporting features to older releases
creates fragmentation and a race to the bottom that ultimately does our
users a disservice for the benefit of some brand recognition or
whatever.

I speak personally, not for Oracle, when I say that I think all these
feature backports are bad.

> 
> 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 don't think "open core" is morally bad, but I agree that there's ample
evidence that roping off the "best" features stifles innovation and
adoption. It also creates a nasty dynamic in the community where rather
than cooperating on the shared feature set you'll see competitors
spending most of their time reverse-engineer or trying to provide
alternatives to those differentiating features, which gets messy fast.

At least our team is not doing closed features any more, but I can't
speak for Oracle strategy in neither the long nor short term. I hope
we'll continue our OpenJDK strategy of full openness and cooperation on
the mainline, and I personally hope we'll take steps to be more open and
active in the updates projects, too.

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

That it's bad to force the risk imposed by adding well-meaning features
on people who expect only stability and security fixes is a technical
argument.

The argument is that the acceptable risk to impose on risk-averse people
depending on a LTS for operations of stable systems should be "none",
unless that risk is absolutely necessary to take for the continued
operation of the service. The TLS 1.3 feature might be the only one I've
seen in these discussions that I think meets that bar. And it's a good
bar.

/Claes

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