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

[Ron Pressler]

> On 28 Nov 2024, at 07:25, Karsten Silz <karsten.silz at gmail.com> wrote:
> 
> Whoa, now you're really throwing me a curveball here! :-) I'm sorry, but I do not find either of these assumptions in the JEP. And I think that Spring Boo does not follow them.
> 
> The first assumption is that "users who deploy update releases of an older JDK (17, released three years ago) prefer stability over new functionality". This sounds like you cannot baseline your tip on an older LTS release, like JDK 17.

“Users” here refers to *application developers* (i.e. the library’s and the JDK’s ultimate users), as they are the only users who deploy any kind of JDK runtime. Library developers don’t deploy any runtime of any version.

> 
> The second assumption is that "users who wish to obtain new functionality can and will upgrade to newer libraries and JDKs". That sounds like a library must bundle new features with new JDK releases. Again, I don't see that in those JEP bullets I quoted above. 

Again, “users” refers to application developers, as they are the only users who deploy any kind of JDK runtime. JDK choice (by application developers) and JDK baseline choice (by library authors) are not the same thing. The former enables but does not mandate the latter. So it’s not “must” but “can". T&T makes life easier for library developers and delivers better libraries to users by not only reducing maintenance costs but by *allowing* libraries to make use of new JDK features if they’re helpful to the library and its users.

Put another way, developers of actively maintained applications can (and therefore should) use the current JDK. Consequently, library developers *can* have a recent baseline in tip releases aimed at those users.

> 
> Spring Boot, Quarkus, and Micronaut all have a JDK 17 baseline for the tip and deliver new features with that baseline today, not matching the first assumption.

The assumption is about application developers, not library developers. If library authors conclude that a new baseline will not offer much to the library, then there’s no reason for them to adopt it. Because they can, they should consider this option, but that doesn’t mean they should blindly change their baseline just because they can.

> 
> Library authors may also be interested in reaching the widest audience possible. Especially commercial ones that depend on support & training fees. If Spring Boot 3.2 had switched to JDK 21 in November 2023, then in March 2024, four months after its release, only 1.4% of all Java users could have run it in production. That's compared to 35.4% that could run JDK 17 then. Even now, two years after Spring Boot 3.0 bumped the baseline to JDK 17, maybe only 50% of all Java users can run Spring Boot 3.x.

T&T allows library users to adopt new features when they want them. The wide audience is reached by offering tip AND tail, and that audience is better served, and at a lower cost, than with one-size-fits-all. That most/all of the audience should be at the tip is precisely the mistake made by developers of one-size-fits-all (i.e. tip-only) libraries, and results in people who want stability and people who want the most value both not getting what they want.

That is pretty much the whole point of T&T: that the broadest, widest audience is not reached most effectively with the same version.

> 
> So, when libraries switch the tip to new JDK releases quickly, they restrict the tip releases to the few percent of Java that can actually run these new JDK versions in production. This may be fine for some or many libraries – Spring Boot did this with Spring Boot 3 and JDK 17. But I can understand why some librariy don't want to limit their audience that heavily and regularly.

That does not limit the audience and you’re still confusing JDK choice with JDK baseline choice. The library chooses the appropriate baseline for the features it wants to deliver.

> 
> The JEP says, "It is not necessary to develop tip releases in lock step with the JDK's six-month tip releases." You seem to scold libraries that don't. So, is not being in "lock step with the JDK's six-month tip releases" still T&T?

This is the same JDK vs. JDK baseline confusion again. A library (regardless of whether it does T&T or not) should support the latest JDK always. That does not mean that it should be *baselined* on the latest JDK.

> 
> 
> While we're at it: I never understood this argument: "it makes sense to adjust our future LTS releases to a two year cadence.  [...]  It also makes the use of six-month releases more appealing as organizations know the next available LTS will always be less than two years away. " Why does a two-year cadence make non-LTS versions more appealing? Most Java users were happy to skip five non-LTS releases and wait three years for the next LTS release in the past. Why would they start using non-LTS now that they only have to skip three non-LTS releases and wait only two years?

Most Java users were also happy to use tip releases only in the 20 years before there were LTS offerings to support legacy applications. Most Java users probably didn’t even know that 7u4 was a feature release while 7u5 was not, that 8u20 was but 8u25 was not.

Most users of any product are “low-engagement users” (unless the product is immature or highly niche). They use the product regularly, but they don’t closely follow its evolution — they have other things to worry about. But the smaller portion of the high-engagement users have a bigger impact on its evolution, and they tend to extract more value from it.

Those who are more engaged and follow things more closely — as they want to get more value — will find it more reassuring to know that they can wind down the maintenance of their application (and make it “legacy”) every two years, which reduces the risk of adopting the tip train. The cost of staying on the tip is negligible for actively maintained applications, but it is not negligible for legacy applications (as their maintenance investment is close to zero). If you’re uncertain about the investment prospects for your project, knowing you can turn it “legacy” every two years instead of three helps make decisions.

In fact, most messaging is expected to affect mostly high-engagement users, as they’re the ones most likely to hear it. Even the message that developers of actively maintained applications will have a better experience if they used the current JDK is expected to affect high-engagement users, but they’re the ones who seek to extract the most value from the platform.

— Ron