...

[Claes Redestad]

On 2020-06-30 08:03, Roman Kennke wrote:
> How is the JFR backport any different, though? One major vendor
> included it in their commercial offering. Other vendors wanted to
> include it too, in an 8u LTS that was arguably much longer down the
> path of stabilization. There was nothing broken in OpenJDK 8u as it
> was, that needed fixing IMO. It would have been just as reasonable to
> tell users who want JFR in their JVM to use a later LTS instead. And it
> came with very considerable risks, I'd argue with much higher risk than
> adding Shenandoah, because it required hooks and changes all over the
> VM. Why is it treated different, then? What qualifies JFR as necessity
> that justifies taking such high risk in such a mature and stabilized
> release? Why didn't we have this discussion back then?

I made the case back then that backporting JFR was the wrong call,
mainly on the basis that what was proposed to be backported was
essentially a very much reworked feature that had had a lot of brain
surgery compared to the JFR in Oracle's 8u. What's now offered in
OpenJDK 8u is *not* a drop-in replacement to the JFR Oracle JDK has in
8u. Something on the surface very similar to it, sure. But not the same
thing.

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.

$.02

/Claes