One of the driving factors behind our next major version, Vaadin 25, is the upcoming release of Spring Framework 7 and Spring Boot 4. The new Spring versions are in turn based on Jakarta EE 11 which has Java 17 as the minimum version. Spring plans to use that same Java 17 baseline requirement while also ensuring compatibility with newer Java versions.
We also followed the same scheme in our initial planning for Vaadin 25 but we are now asking ourselves if Java 21 would be a better baseline? This is only a question about the minimum supported version â we would regardless make sure Vaadin remains compatible with newer Java versions.
Vaadin 24 (March 2023) raised the minimum to Java 17 (September 2021).
While Java 11 in Vaadin 23 felt like a big step, the same was not the case with Java 17 in Vaadin 24 even though Java 17 was relatively speaking much newer.
It seems like many have started to keep their Java versions more up-to-date after the some initial friction from getting beyond Java 8. This is also reflected in JEP 14: The Tip & Tail Model of Library Development which encourages library developers to adopt new Java versions relatively quickly while offering reduced maintenance without introducing new features for older library versions that support older Java versions.
Is Java 21 old enough?
At Vaadin 25âs planned release in December 2025:
Java 21 will be a bit over 2 years old (September 2023). This is older than what Java 17 was for Vaadin 24
Java 17 will be over 4 years old. This is even older than what Java 11 was for Vaadin 23.
One of the main themes around the way we plan our releases is to encourage continuous updating rather than allowing the pile of pending updates to grow until it becomes too big to handle in a reasonable way. We like follow our own teachings by keeping our own versions, including Java itself, reasonably up-to-date. If we donât make a small change to the Java version requirement now, the we might instead end up doing a bigger and potentially more challenging update later instead.
Java 25 (the next LTS) will also be recently released by then but we donât think itâs reasonable to make that a minimum requirement for Vaadin 25 (though Vaadin 25 with Java 25 would be a sweet combo with Vaadin having its 25th anniversary in 2025 ).
Java 21 features that we want to use
Virtual threads would be useful for event handling with full-stack signals. We are also making Modernization Toolkit provide support for Swing code that expects e.g. confirm dialogs to block the UI thread during user interactions.
While basic records are available already in Java 17, the addition of pattern matching for records introduces a new dimension to how we can design APIs. It also allows us to write clearer and more maintainable implementation code.
Sequenced collection interfaces could be used in some APIs as a promise/reminder that ordering will be preserved through the use of e.g. LinkedHashSet over the regular HashSet.
None of these features are critical for anything we plan to do but they would all provide some specific nice benefits and overall help us keep things more simple and maintainable.
Reference
Recent Vaadin and Java version history if Vaadin 25 would require Java 21.
Iâd go with Java 21. Here we try not to fall behind, every new project will be with Java 21, and some older but still in use were migrated. No need to stick with Java 17 IMHO.
Multi-release JAR is a good solution for making performance improvements available to those who have a newer Java version or for dealing with cases where thereâs no baseline API that is available in all versions.
But a multi-release JAR doesnât help at all with API design since you would create a huge mess if the same feature has different APIs on different Java versions. And it makes thins even worse when it comes to maintainability of our own code since we would still have to keep the old and âbadâ implementation around and additionally also make sure it stays in sync with a newer version.
We could build something that automatically becomes more performant when virtual threads are available but we cannot introduce an architecture that is based on having thousands of blocking threads.
Iâm afraid that your point there about Spring Boot rejecting libraries that require Java 21 might force our hands here.
If Vaadin 25 requires Java 21 that means you canât run Vaadin for all the Spring Boot 4 app.
And have no way to run it with Java 17.
It might be annoying in big company. Itâs also confusing to update because of Spring Boot but not following the requirements.
The Spring maintainers expects most Spring Boot 4 apps to use Java 21 even though they would also support Java 17. In their words, use of Java 17 would be âtoleratedâ but not âpromotedâ.
The big question from that point of view is how common it would be for companies to be eager to update one specific dependency (Spring Boot 4) immediately when a new version is released while at the same time not updating another dependency (Java 21) even though over two years have passed since it was released.
I understand itâs not always that easy since the Java version might be centrally managed whereas the Spring Boot version is more likely up to each application to decide on their own. But the question is still how common that scenario would be?
Thereâs also a possibility that Spring Boot 4 will be backwards compatible enough that it could be feasible to use it together with Vaadin 24. But thatâs something we will know only when the full extent of changes on the Spring side are known. We will anyways have Spring Boot 3 as the primary version for Vaadin 24 and Spring Boot 4 as the primary version for Vaadin 25.
The bigger the company⊠the bigger the likelyhood of this scenario. Let me for example use Debian - even now, the current Debian stable has no Java 21 available (openjdk-21 - Debian Package Tracker), forcing people to install it from another repository⊠which is really offsetting for some companies. Host systems are normally managed by other teams and to convince them to install something that is not directly in their distro takes time.
When would the next window of opportunity open then if you donât go for Java 21 in Vaadin 25 ? Is Vaadin 26 scheduled a year later ?
Apart from perhaps the signal feature (but i donât really know what exactly it is?) I donât see the arguments brought forward as âcompellingâ or providing such additional customer value that they would outweigh the doubts that have been raised.
Debian 13 is expected at some point in 2025 and should have Java 21. I definitely expect that everyone will update their Debian setups immediately when the new version is released so that should align nicely with Vaadin 25 by the end of 2025.
We aim at doing a new major release every 12 - 24 months. We adjust the exact timing based on our development pipeline and changes in the wider ecosystem. The time between Vaadin 24 and Vaadin 25 will end up at 33 months since wanted to align with the Spring schedule.
This means that the next natural opportunity would indeed be one year later in December 2026 but thereâs also a possibility that circumstances will align for something like the 33 month interval between 24 and 25. In that case, Vaadin 26 would be in September 2028.
But that would still not address the other concern expressed here, which is that some applications that use Spring Boot 4 would not have any compatible Vaadin version to choose.
One of the key points behind the release model that we adopted in the beginning of 2022 is the thought that open source development should be able to move at the speed of open source. This is enabled by the same âTip & Tailâ model that OpenJDK has subsequently also documented: the latest version is continuously kept in a modern state with regular feature updates while older versions remain supported with infrequent updates that mostly just keep that version secure and compatible. Vaadin 14 is the last version with Java 8 support and will be maintained until 2034 which is longer than any JDK vendor has plans to maintain Java 8.
An organization that prioritizes continuous technology updates should have no problem sticking to the latest Vaadin version. But weâre not ashamed of suggesting that organizations with other priorities need to pay for the luxury of updating less frequently (if ever). This is mainly justified by the additional effort required for maintaining those versions. But another factor is the fact that developers want to use the latest tools â itâs easier to justify that someone must use older tools with âwe get paid for doing itâ than with âthatâs just the way it isâ.
I think this model works quite well in general but there is one âbugâ: teams that prioritize updating the things that they have control over while operating in a larger organization with other priorities. Our model doesnât always allow them to have their organization pay their way out of that situation so that they could still use the latest versions of the tools that they can control.
From that point of view, the jOOQ model is just pure genius. Not only will enterprises have to pay if to use an âenterprise databaseâ but paying will also provide compatibility with older open source database versions and older Java versions. Quick developers can update the latest version of jOOQ right away and then they can tell the slower rest of the organization that they have to take responsibility for being slow by accepting the cost of the needed commercial jOOQ plan. In that way, most of the pain of being slow goes to the party that is empowered to make changes.
I wonder if something similar would make sense also for Vaadin?
I think an existing application wonât necessary update to Spring boot 4 faster than Java 21.
But if youâre building a new application in that environment you will probably use the latest version Spring boot 4 and Vaadin 25 and⊠crap we have Java 17. Then you have to use Spring boot 3 and Vaadin 24.
I have no idea how common this scenario is. It was more common for Java 8, still exist because of java 8 I guess
).
I would be against Java 21 (as of now as well) - but this position could changeâŠ
