Hotspot Express (HSX)

[Ron Pressler]

On 28 February 2020 at 11:30:19, Volker Simonis (volker.simonis at gmail.com(mailto:volker.simonis at gmail.com)) wrote:


> Some people claim that there are no more major Java releases since
> Java 9 

"Major releases” don’t have a precise definition, but that major releases
*as they were in Java up to 9” clearly and factually no longer exist, as
as any examination of the release notes would confirm.


> and every new feature release (i.e. 10, 11, 12, etc.) is
> nothing more than a normal update release like 8u20, 8u40, etc in the
> old Java 8 days. 

Not *nothing* more, but *little* more, as confirmed in practice by
those who do these migrations regularly.

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

> Such problem clearly never happened in update
> releases like 8u20, 8u40, etc in the past.

This is not true, as an examination of the bug database would 
confirm. 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, and while it will always be somewhat more (in exchange
for no more major upgrades), the amount of additional work required
is constantly decreasing as more libraries and tools (Spring, Gradle)
are supporting the current model.


> The proposal is about evaluating the advantages and drawbacks of HSX
> in a new project.

Paul said something about stability of the old major release, but of course
you believe the current JDK to be stable (at the very least modulo changes to
javac/libs, though I don’t know why they'd be less stable than VM changes) or
you wouldn’t propose HSX, which depends on that assumption. You’re suggesting to
take code you trust to be stable but that your customers might not, have a small
team subtly change it, and then package the result under a label that would
sound more stable to some customers who might not be as educated as we are on
the changes to the OpenJDK’s development process and version naming scheme.

True, there are migration challenges, but we know they're rather small, post 9,
from people who have gone through them, and we're working with members of the
ecosystem to make them smaller still. Also true, some fear that OpenJDK will
remove a feature they rely on. But entrenching a mistrust for OpenJDK’s general
commitment to backward compatibility because it's somewhat changed — to be more
sustainable — is a mirage. For example, now that CMS is no longer
maintained in tip, it is likely to de facto become unmaintained in Updates; same
for Nashorn when it is removed. Yet customers might not realize that; if we
don’t explain it to them, why should they? Projecting an image of "everything is
as it was" might help calm them in the short term, because change is scary, but
is harmful in the longer term because the change is real, and HSX can't undo it. 
The upside is that the new model is better than the old one; there's no need to 
reach for an approach conceived when things weren’t working as well.

What I propose instead is to educate customers on the changes to OpenJDK’s
development and release process, and explain to those who wish to enjoy the
enhancements in the JDK that it is stable — or, at least, stable enough for
those benefits important to them to outweigh the risk — that they should just
use it. It's  significantly cheaper and less risky than adopting a competing
platform. And if the risk is real, and to some extent I suppose it is, those
who, over anything else, wish to avoid it will be better served by a
conservative approach that reduces it than by one that hides it.

- Ron

> >
> > > On 26 Feb 2020, at 17:12, Hohensee, Paul wrote:
> > >
> > > And, when jdk17 ships, it would affect only jdk17u.
> > >
> > > Paul
> > >
> > > On 2/26/20, 1:50 AM, "jdk-updates-dev on behalf of Dalibor Topic" wrote:
> > >
> > >
> > >
> > > On 26.02.2020 01:16, Volker Simonis wrote:
> > >> The proposed HSX approach isn't gonna change this at all. It will always
> > >> use the latest released HS version in the current LTS JDK.
> > >
> > > Thanks for clarifying that your proposal would affect OpenJDK 11 Updates
> > > only, Volker.
> > >
> > > cheers,
> > > dalibor topic
> > >
> > > --
> > > Dalibor Topic
> > > Consulting Product Manager
> > > Phone: +494089091214 , Mobile: +491737185961
> > > , Video: dalibor.topic at oracle.com
> > >  
> > >
> > > Oracle Global Services Germany GmbH
> > > Hauptverwaltung: Riesstr. 25, D-80992 München
> > > Registergericht: Amtsgericht München, HRB 246209
> > > Geschäftsführer: Ralf Herrmann
> > >
> > >
> > >
> >