[External] : Re: New informational JEP: 14: The Tip & Tail Model of Library Development

[Alex Buckley]

On 11/23/2024 5:29 AM, Karsten Silz wrote:
> You're making two assumptions here: Users who don't update the JDK
> don't need new library features. And that users have no problem
> upgrading from JDK 17 to 21.

Those are the two assumptions of T&T: that users who deploy update 
releases of an older JDK (17, released three years ago) prefer stability 
over new functionality; and that users who wish to obtain new 
functionality can and will upgrade to newer libraries and JDKs.

> It's easy to find examples where your assumptions don't hold. For
> instance, a company can have a JDK 17 tech stack but create new
> mircoservices where they try out new Spring Boot 3.2/3.3 features.

The range of deployment scenarios that rely on the JDK is enormous, and 
there are edge cases where T&T doesn't align with the expectations of 
some users. One edge case consists of users running JDK 8 today who 
expect new functionality in libraries, the Java language, the JDK class 
library, etc, to be backported. Another edge case consists of users 
running JDK 17 who struggled to get there from 8 and view further 
upgrades to 21 as not worth the cost; they expect library maintainers to 
bear the cost instead, by backporting new features to a library version 
that still supports 17. But 17, like 8, is now a "mature" tech stack 
intended to run existing code as stably as possible. If you're expecting 
to develop new microservices, T&T expects you to do it on a new JDK.

Since T&T wasn't known until recently, allow me to paint a picture of 
what would have happened with Spring Boot in a fully T&T universe. 
Spring Boot 3.2 and 3.3, having been released after JDK 21, would have 
been baselined on JDK 21 rather than JDK 17. Users who create new 
microservices would be upgrading from 3.0/3.1 to 3.2/3.3 to enjoy new 
features, and upgrading from JDK 17 to JDK 21 for exactly the same reason.

> Or a JDK 21 deploment held back because a dependency or something in
> the build pipeline or in the observability statck not supporting JDK
> 21.

I referred earlier to users who struggled to upgrade from JDK 8 to JDK 
17. The struggle was not due to "modules" or the removal of 
sun.misc.Unsafe (which of course is just as available in 17 as in 8). 
The struggle was due to a small number of widely deployed tools and 
libraries which assumed that undocumented JDK internals would never 
change. It's fair to say that everyone now realizes this assumption is 
invalid. Library maintainers know they're living on borrowed time if 
they have to advise users, "Run with --add-exports on JDK 17" -- the 
internal class that's exported could disappear in the next 17.0.x release.

Having survived that trial by fire, the Java ecosystem post-17 is in 
much better shape. Upgrading from 17 to 21 is typically a matter of 
letting Maven upgrade your dependencies. In the increasingly rare cases 
of tools and libraries that *still* don't support JDK 21, their issue 
trackers are often full of users trying to explain to maintainers that 
JDK 17 isn't the latest Java anymore -- and full of responses from 
maintainers about how they don't want to abandon users on JDK 17 by 
mandating JDK 21. This one-size-fits-all mentality by maintainers is 
exactly what T&T seeks to overcome. They can offer a 17 train at low 
cost because *it has no new features*, and offer a 21 train that adapts 
to whatever is new in JDK 21.

If anyone reading this is held back from deploying on JDK 21 because of 
"a dependency or something in the build pipeline or in the observability 
stack not supporting JDK 21", please let the relevant maintainers know 
about JEP 14 so they can get to grips with T&T ASAP.

There are users running an Early Access of JDK 24 today in advance of 
deploying it next March. They're frustrated with tools and libraries 
that can't seem to grasp how there's a new production-ready feature 
release of the JDK every six months. If this seems astonishing to you, 
look at Stream Gatherers -- JEP 485 -- and think about all the streams 
you've written where you wished for this feature. (And no, it won't be 
backported to JDK 21.)

Alex