<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Alex, thank you very much for your long reply! <div><br></div><div>I'm sorry for asking all these questions. But half a year ago, Mr. Goetz issued "a bit of a call to action" on T&T (<a href="https://www.youtube.com/watch?v=YBGVK5JuSJ8&t=2421s">https://www.youtube.com/watch?v=YBGVK5JuSJ8&t=2421s</a>). <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">I want to write about this for InfoQ, so I need to understand it before explaining it to my readers. </span>But that call to action was light on details. The talk at the JVM summit had a bit more details (<a href="https://www.youtube.com/watch?v=NV4v7KXKQ-c&t=1320s">https://www.youtube.com/watch?v=NV4v7KXKQ-c&t=1320s</a>) but still not enough for me. When I saw the JEP, I thought, "Well, finally, this is going to tell me how to do T&T". But it doesn't because it's just the philosophy, as you explained. </div><div><br></div><div>I do not know if and when you guys will say more about T&T, apart from answering questions from annoying folks like me. :-) So, if you'll publish more details on T&T soon, please disregard my questions.</div><div><br><div><blockquote type="cite"><div>On 25 Nov 2024, at 22:04, Alex Buckley <alex.buckley@oracle.com> wrote:</div></blockquote><blockquote type="cite"><div><div><br>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.<br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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. But in the "Picking a JDK baseline" section, the JEP only says, "In the tip train, baseline each tip release on the JDK version that best supports the library's new features and enhancements." I read that as "A library is free to pick whichever JDK it wants as the baseline." Mr. Goetz' slide was more restrictive: It stated that the "latest version of a library [should be] baselined on selected recent JDK version". That "recent" is missing from the JEP.</div><div><br></div><div>A little further down, a bullet says: "It is typical to bump the JDK baseline of the tip train when the library needs new JDK features." I'm unsure if it is a general recommendation, as it's derived from an example in the JEP. Let's assume it is. <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">It's still a recommendation to me, as </span>it does not say, "Thou shall always bump the JDK baseline". So, if you do not bump the baseline, you may not be a "typical library", but you can still be T&T in my eyes.</div><div><br></div><div>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. </div><div><br></div><div>Spring Boot, Quarkus, and Micronaut all have a JDK 17 baseline for the tip and deliver new features with that baseline <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">today</span>, not matching the first assumption. Helidon has a JDK 21 baseline, so it does match it. Spring Boot will even keep that JDK 17 baseline at least until November 2027: <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Spring 7, starting in November 2025, retains JDK 17 – but upgrades to Jakarta EE 11 and Kotlin 2. Mr. Hoeller announced this the day after you created the JEP (</span><a href="https://spring.io/blog/2024/10/01/from-spring-framework-6-2-to-7-0">https://spring.io/blog/2024/10/01/from-spring-framework-6-2-to-7-0</a>)<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">. </span></div><div><br></div><div>Spring Boot (and Quarkus and Micronaut, I think) support new JDK versions quickly on the tip through multi-release JARs, but do not bump the baseline. So, users get new functionality without upgrading the JDK, not matching the second assumption, either.</div><div><br></div><div>Users cannot get new JDK functionality when staying on JDK 17. But for Spring Boot, barely any new functionality seems to depend on JDK versions greater than 17. Spring Boot 3.0 switched to JDK 17. The only new JDK feature I could find mentioned in the Spring Boot 3.1-3.4 release notes (go to <a href="https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.1-Release-Notes">https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.1-Release-Notes</a> and then pick 3.2-3.4 on the right) was virtual threads: Introduced in 3.2, spreading to more places in 3.3 and 3.4. More features may require new JDK versions, but the release notes didn't say.</div><div><br></div><div>Could you point out where these two assumptions are expressed in the JEP? And does Spring Boot <font color="#000000"><span style="caret-color: rgb(0, 0, 0);">follow T&T, </span></font>with a JDK 17 baseline on the tip, <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">even after JDK 25 is released next year,</span> <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">and the use of multi-release JARs</span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> to support new JDK versions?</span></div><div><br></div><div><div>Here's a thought: OpenJDK does T&T. And T&T talks about the baseline. Do you consider the operating system the baseline for OpenJDK? :-)</div><div><br></div><div>If so, then the Oracle JDK does not follow these two assumptions. Oracle JDK 23 supports four macOS versions, three Windows server versions, two Windows Client versions, and a lot of Linux versions (<a href="https://www.oracle.com/java/technologies/javase/products-doc-jdk23certconfig.html">https://www.oracle.com/java/technologies/javase/products-doc-jdk23certconfig.html</a>). <font color="#000000">Oracle JDK 21 supports one </font><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">macOS version that Apple does not support anymore and two Ubuntu versions that Canonical stopped supporting (</span><a href="https://www.oracle.com/java/technologies/javase/products-doc-jdk21certconfig.html">https://www.oracle.com/java/technologies/javase/products-doc-jdk21certconfig.html</a><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">). Finally, Oracle JDK 17 tops that with three unsupported Windows versions, three unsupported macOS versions, and six unsupported Linux versions (</span><a href="https://www.oracle.com/java/technologies/javase/products-doc-jdk17certconfig.html">https://www.oracle.com/java/technologies/javase/products-doc-jdk17certconfig.html</a><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">). </span></div></div><div><br></div></div><div><blockquote type="cite"><div><div>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.<br></div></div></blockquote><div><br></div><div><div>When you say, "in a fully T&T universe", does that mean that either now or in the future, T&T will require libraries to quickly baseline on new LTS JDK versions? Again, I didn't find that as a requirement in the JEP.</div><div><br></div><div>You suggest Spring and Spring Boot should <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">change their Java baseline during a generation.</span> Spring has not done this for a while, if ever. And the next generation will stick with JDK 17, as mentioned above. I got <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">to ask Mr. Hoeller why. Here's his answer (</span><a href="https://www.infoq.com/news/2024/11/spring-6-2-spring-boot-3-4">https://www.infoq.com/news/2024/11/spring-6-2-spring-boot-3-4</a>):<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> </span></div><div><br></div><div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">"Our baseline is usually derived from technical concerns. Java 17 provided so much goodness over Java 11 (the alternative choice at the time) that we went with it for Spring Framework 6.0 right away, dramatically modernizing our codebase and pushing the industry overall – at the expense of making the upgrade path harder, in combination with the Jakarta EE namespace change at the same time.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">For Spring Framework 7.0, there is hardly any technical benefit in a Java baseline upgrade. Specific features against newer Java versions can easily be provided through multi-release jars, as we do for Virtual Threads in Java 21 already. The current industry consensus is clearly around a Java 17 baseline, for example, with the Jakarta EE 11 APIs and the upcoming provider generation there. Since our current framework codebase would not benefit from a baseline upgrade, we are aiming to stay on a Java 17 baseline while providing first-class support for Java 21 as well as Java 25 in the same generation. Instead, our baseline raise comes with Jakarta EE 11 APIs, such as Jakarta Servlet 6.1 and Jakarta Persistence 3.2, as well as Kotlin 2.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">We generally recommend the latest Java LTS generation for production deployment, independent from the underlying baseline, which is effectively just a technical minimum that the framework tolerates at runtime. For Spring Framework 7.0, despite a Java 17 baseline, our focus is clearly on embracing Java 25. Looking forward, we can see Java 25 becoming an attractive new baseline for the wider Java ecosystem at a later point. However, for the time being, the best we can do is to support it as part of our JDK version range."</div></div><div><br></div></div>L<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">ibrary 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 </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">in March 2024, </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">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.</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">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. </span>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.</div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">I got the JDK distribution numbers from New Relic's "</span><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">2024 State of the Java Ecosystem</span></font><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">". The PDF download is at </span><a href="https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem">https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem</a>, then go to page 5<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">. They probably collected the data in March 2024: "</span><font color="#000000">In the six months after the release of Java 21". New Relic's data "</font><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">is based </span><font color="#000000">on data gathered from hundreds of thousands of applications reporting to New Relic that provide performance information</font><span style="color: rgb(0, 0, 0);">". The report is obviously biased towards the kind of customers that use New Relic. </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">But these numbers are the best ones I got. </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">At Oracle, you may have other numbers.</span></div><div><span style="color: rgb(0, 0, 0);"><br></span></div><div><span style="color: rgb(0, 0, 0);">I don't take surveys into account because I</span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> haven't seen many good ones in the Java world. For instance, the JRebel "2022 Java Developer Productivity Report" surprised the world by predicting that 37% of the surveyed Java developers want to upgrade to Java 17 by July 2022 – less than a year after its release (</span><a href="https://www.jrebel.com/resources/java-developer-productivity-report-2022">https://www.jrebel.com/resources/java-developer-productivity-report-2022</a>): The<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> survey ran from October 2021 to January 2022, and the answer was "Upgrade to Java 17 within the next six months". According to New Relic, Java 17 probably was indeed at 37% in July – but 2024, not 2022. :-)</span></div><div><br></div><div><blockquote type="cite"><div><div>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.<br></div></div></blockquote><div><br></div><div>I do not speak for Spring Boot. But I've written about Spring Boot releases in the past. So, I can think of three reasons why Spring Boot users on <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">JDK 17 are happy to get tip releases still.</span></div><div><br></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">First, </span></font>a tip release has all the bug fixes, a tail release gets only the critical ones. Second, as mentioned above, most new Spring Boot features do not depend on new JDK features and are available on JDK 17. Third, Spring ecosystem projects (Spring Data, Spring Batch, Spring Security, Spring Integration, …) recommend or require new Spring Boot versions, as do non-Spring libraries with<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> auto-configuration through Spring Boot.</span> That may actually be the biggest reason to upgrade: Users want new library versions and must upgrade Spring Boot, even though they may not care much about it. And every couple of years, Spring Boot makes them upgrade Java – if they haven't done so by themselves.</div><div><br></div><div>I think the first two reasons may apply to other libraries. The last one may be specific to Spring.</div><div><div><br></div></div><blockquote type="cite"><div><div>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.</div></div></blockquote><div><br></div><div>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 "<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">lock step with the JDK's six-month tip releases" still T&T?</span></div><div><br></div><div>Non-LTS JDK versions make up "less than 2%" in production, according to the New Relic report I quoted above. If you add up the numbers on page 5 of their report, it's 1.3%. They analyzed the data in March 2024, six months after JDK 21. But even if we assume that everybody in the 1.4% on JDK 21 came from JDK 20 and not JDK 17, that's still a total potential of only 3% for non-LTS versions today. <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Java frameworks have supported new JDK versions quickly for 2-3 years now.</span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> Do the 97% of Java users on LTS versions in production just not know about this today? Will they learn over the next few years? Or do they just not care enough?</span></div><div><br></div><div>Now, these numbers are different from what Oracle cited three years ago: "developer surveys show six-month (non-LTS) releases being used by between a quarter and half of developers surveyed, only about half of those note their use is in production" (<a href="https://blogs.oracle.com/java/post/moving-the-jdk-to-a-two-year-lts-cadence">https://blogs.oracle.com/java/post/moving-the-jdk-to-a-two-year-lts-cadence</a>). That comes up to 6.5-12.5% using non-LTS versions in production. I don't know the survey he's referring to, but I am skeptical of surveys – see above.</div><div><br></div><div>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 <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">were happy to </span>skip five non-LTS releases and wait three years <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">for the next LTS release in the past.</span> Why would they start using non-LTS now that they only have to skip three non-LTS releases and wait only two years?</div><br><blockquote type="cite"><div><div>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.)<br></div></div></blockquote><div><br></div>I'm more of a loop guy. ;-)</div><div><br></div></div><div>Do you have any telemetry data or analysis of public Java code (e.g., on GitHub) that shows which percentage of Java programs use newer JDK features?</div><div><br></div><div><div><br></div><div>Regards,</div><div>Karsten Silz</div></div></div></div></body></html>