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

[Karsten Silz]

Hello Mr. Buckley & Mr. Pressler!

I understand why you haven't answered some of my questions – you're busy, and my questions were sprinkled throughout my posts.

That's why I guessed your answers and put these guesses below. I also added some of your previous answer to wrap up my postings on this topic. Please tell me which assumptions I got wrong. Thank you! 


(1) The first core assumption of T&T is: Users who deploy update releases of an older JDK (such as JDK 17 in 2024) prefer stability over new functionality in libraries and JDK.

(2) The second core assumption of T&T is: Users who wish to obtain new functionality can and will upgrade to newer libraries and JDKs.

(3) These two core assumptions do not directly restrict how library maintainers implement T&T. They do so indirectly – by informing the "dos and don'ts of T&T".

(4) Although the JEP includes "dos and don'ts", it's not a complete, fully actionable guideline for implementing T&T. Instead, it outlines the philosophy behind T&T and explains why T&T exists.

(5) The JEP authors have yet to decide if and when they will publish a complete, fully actionable guideline for implementing T&T.

(6) All Java libraries should use T&T, even if their maintainers believe to be unaffected by some or all the problems T&T sets out to solve.

(7) T&T requires library maintainers to provide a tail that meets the needs of stability-focused users over an extended period of time.

(8) T&T does not require libraries to support every non-LTS JDK release on their tip.

(9) T&T does not require libraries to baseline their tip on the latest LTS JDK release.

(10) Spring Boot follows T&T, even though it delivers new features to users on JDK 17 and will keep a JDK 17 tip baseline after JDK 25 is released.

(11) The JEP does not distinguish between tail releases with dependencies that have new features and tail releases without such dependencies.

(12) For the OpenJDK implementation of T&T, the operating system is the baseline.



Regards,
Karsten Silz


> On 28 Nov 2024, at 14:04, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
>> 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.

I was wrong. Even worse, I was irrelevant. :-( Thank you for making me think! 

And I hope I did not confuse library users with library maintainers. I thought the library maintainers' actions reflected their users' wishes. They don't.

T&T assumes users on JDK 17 prefer stability over new features. But Spring Boot, like most Java frameworks, ships new features to JDK 17 users. Why is that? I think it's because library maintainers can justify that no matter what.

If the maintainers also assume (or know) that JDK 17 users prefer stability over new library features, then the minority of users preferring new features can still be sizable. So, shipping new features to them makes sense if it's cost-effective to support multiple JDK releases. If, on the other hand, the maintainers think (or know) that most JDK 17 users want new library features, shipping these new features is a no-brainer. And finally, even if the maintainers think (or know) that nobody on JDK 17 uses new features, they could still ship new features to stay competitive with other libraries that do.

But that was also irrelevant because the two T&T assumptions (statements 1 & 2 above) do not restrict the library maintainers' actions. The "dos and don'ts" in the JEP do (statement 3 above). At least, that's my assumption. :-)

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

I'm sorry for being imprecise: It limits the audience for new library features.

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

First, you say that "a library [...] should support the latest JDK always". I did not find this recommendation (or requirement?) in the JEP. Instead, the JEP says, "baseline each tip release on the JDK version that best supports the library's new features and enhancements" and "it is typical to bump the JDK baseline of the tip train when the library needs new JDK features". Leaving out the baseline business, neither reads to me as "a library should support the latest JDK always". That's why my statement (8) says, "T&T does not require libraries to support every non-LTS release on their tip". What am I missing here?

Second, about this baseline business. You say that supporting the latest JDK "does not mean that it should be 'baselined' on the latest JDK". The JEP suggests otherwise: "it is typical to bump the JDK baseline of the tip train when the library needs new JDK features". Are you just proposing a non-typical approach to JDK baselines in T&T? 

And the only way I know how to do what you suggest is multi-release JARs – and Mr. Buckley ain't a fan: "Using an MRJAR to achieve 'baseline on 17 but support new 21 features' will IMO be more costly for a long-term tail than saying: 3.j is baselined on 17 and doesn't use virtual threads, while 3.k is baselined on 21 and does use virtual threads" (https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009527.html) Are there multi-release JARs alternatives embraced by the JEP authors?

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

This may be a fine answer. A tad wordy, perhaps. I just don't know the question – it certainly wasn't mine. :-) 

I asked: Why does making something less valuable also make it more popular? Again, thank you for making me think, as that was half-wrong.

Yes, a two-year LTS cadence makes non-LTS releases a third less valuable vs. LTS releases – 6-18 months early access to new JDK features now vs. a 6-30 months before. But it's also a third cheaper – four JDK upgrades instead of six. Still, an identical cost-benefit ratio on non-LTS releases does not predict increased popularity. 

Now it's possible that even at lower value, a lower cost pushes non-LTS releasese below a threshold where they become more popular. Alas, they did not – if we can believe New Relic's numbers (see my last post at https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009668.html).


> — Ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20241213/7de52051/attachment-0001.htm>