Hotspot Express (HSX)

Mario Torre neugens at redhat.com
Fri Feb 28 14:15:58 UTC 2020


On Fri, Feb 28, 2020 at 2:57 PM Ron Pressler <ron.pressler at oracle.com> wrote:
>
> > In my opinion, such a claim is simply ridiculous,
> > because most of the 10, 11, 12,.. releases are source and binary
> > incompatible with the previous release (e.g. because the removal of
> > the Corba, EE modules, Nashorn, new keywords, new class file versions,
> > the removal/renaming/hiding of internal classes, etc).
>
> I don’t understand this argument. When Nashorn is removed in 15 how
> will HSX help keep it alive in 11u? When finalizers are removed,
> how will HSX keep them alive?

This is not what Volker is claiming, if I understood him correctly, he
means that current updates across jdks already have incompatible
behaviour introduced via source or binary changes. So there's a
stronger evidence that supporting the LTS for longer is necessary, and
that it would benefit from having a shared Hotspot rather than
backporting single patches.

I see his point, I don't know if I agree with him more or I'm more
inclined to second what Jesper said though, both have valid arguments
to me.

> > Such problem clearly never happened in update
> > releases like 8u20, 8u40, etc in the past.
>
> Sure, the new feature releases require more work than the
> old feature releases. The question is *how much* more? The answer
> is: not that much

Of course, analysing the bug database is a good indication of the
indirect work of feature backport, but I think this sort of answers
can't be given by us directly, but are a result of customer
relationship more than anything else. It's entirely possible that some
customers wanted the HSX features from SAP as Volker suggested and
some other prefer the stability of fine tuned single backport.

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



More information about the jdk-updates-dev mailing list