TL;DR: The Java enterprise application ecosystem at large is making a backward-incompatible leap from the javax.* namespace into jakarta.*. To use next-generation application frameworks like Spring Boot 3 or Jakarta EE 10 compatible application servers, you'll need to use the soon-to-be-released Vaadin 24 (available now in Early Release with GA planned for March 2023). As free support for Spring Boot 2.7 will end in November 2023, and Vaadin 23 free support will end in March 2024, we recommend that you start planning your upgrades to these new versions. Five years of maintenance is included as part of Vaadin's Prime and Enterprise commercial offerings for those who need a longer time to upgrade.
Whether you are using our open-source versions or have a subscription, we'd love it if you could take part in a brief survey to help us understand your plans for migrating to Spring Boot 3 and Jakarta EE 10. The results of this survey will provide us with valuable insights to serve you better during the transition to these new versions.
Spring Boot 3, Jakarta EE 10, and Vaadin 24 will all be backward-incompatible releases. While they may not include major new features, you should still be interested and eager to hop on board, since this upgrade will be a necessary step to keep your application safe and to utilize the upcoming features arriving in minor versions.
The plot around these new releases started to thicken a few years back, when Oracle donated the Java EE specifications and standardization tests to the Eclipse Foundation, where the specifications are nowadays called Jakarta EE. Oracle donated almost everything, except five letters all Java Web developers recognize: javax. The original package name used in various Java EE specifications was only allowed to be used for a short transition period, and since Jakarta EE 9, the javax package name is now jakarta.
Vaadin and Spring have, in many applications, shielded your code rather well from directly using the javax APIs. For example, in my recent upgrade trial, I only had to do raw find and replace to JPA entities, as with Vaadin I'm not directly touching the Servlet API. While Vaadin and Spring usage are not going to change much, nevertheless, the javax namespace leaks to most apps at some level and the frameworks themselves and their transitive dependencies use the namespace extensively. As a result, cutting new major (read: “backward-incompatible”) versions to support Jakarta EE 10 became inevitable.
Neither Spring Boot 3 nor Vaadin 24 will fundamentally change how applications are developed. But, as the jakarta namespace change makes the releases backward-incompatible, both Spring and Vaadin are dropping deprecated features. Notably, in Vaadin 24, we intend to drop built-in support for Polymer templates, which has been deprecated since Vaadin 18 (released in November 2020), in favor of faster and simpler Lit templates. However, we are working on a conversion tool that can assist you in converting Polymer to Lit templates by automating part of the effort. Moreover, it's worth noting that Polymer support will still be available in Vaadin 24 for Prime and Enterprise customers.
Spring Boot is dropping a bunch of outdated small features that already have a replacement in 2.7. So even if you aren't planning to move to the jakarta era in the first wave, it is a good idea to upgrade to Spring Boot 2.7 and Vaadin 23.2 and see what you can do for the usage of deprecated APIs.
And you should also consider all Java versions older than 17 as deprecated technology. Java 17 (current LTS) is the baseline for Spring Boot 3 and Vaadin 24.
What if you can't upgrade?
Although library vendors would always love it if they could get everybody to use the latest and greatest version, we all know this is not possible for many real-world applications. So to help developers cope with this somewhat significant change, the Spring project will provide an extra six months of open source support for the 2.7 series, until 2023-11-18.
The Vaadin 23 series will get free support for one year after the release of Vaadin 24. Vaadin 24 is currently scheduled for general availability in March 2023, and free support on the Vaadin 23 series will extend for one year after that, ending in March 2024. Vaadin users with Prime and Enterprise subscriptions will be able to continue to use Prime, and Enterprise customers will be able to continue to use V23 until 2027 (and until 2037 with Extended Maintenance).
Staying on an older major version may well be the best, or even the only possible, solution for certain applications. But if you plan to halt your major upgrades, the risks regarding security and maintainability with your project will increase as it ages. So be sure to evaluate the risks, actively follow CVEs regarding your dependencies, and consider purchasing commercial support for your most relevant dependencies.
Should you start with pre-releases now?
With existing projects, one should always try to use the latest supported version. If you have extra time in your project, it is fine to test migrating to pre-releases in a separate branch, but pre-releases are not meant for production software.
Also, if you are considering starting a new project today, the primary suggestion from the Spring Boot project is to start with the current stable release (2.7) and then migrate to Spring Boot 3 when it is out. The rationale here is that the upgrade is expected to be relatively smooth after all.
But as the main changes in Spring Boot 3 and Vaadin 24 involve removing deprecated features and upgrading to the jakarta namespace, the pre-releases can be considered quite stable. Therefore, if you are starting a brand new application now, and if you are sure that your application is not going to production until both Vaadin 24 and Spring Boot 3 are in GA, then you can quite safely use the pre-releases during the early development phase. This way, you can avoid the hassle of upgrading to a new major release altogether.
Tip from my hands-on experience: upgrade in small batches
I decided to test out the process of upgrading to Spring Boot 3 with an orienteering application that I maintain pro bono. It has a typical stack for enterprise applications: Spring Data JPA, service layer, and Vaadin UI, for both public and administrative views. Although the application is quite small, the process is similar to that of upgrading larger enterprise applications.
I can’t say the upgrade was trivial but, on the other hand, I can say I did it in the wrong way. Even though my app was relatively recent, it was still running on Vaadin 14.8 (previous LTS, current: 23.1) and Spring Boot 2.6 (2.7.3). I took the risky approach and upgraded everything at once to the latest pre-releases, which affected Vaadin application initialization, the JPA layer, and several direct and transitive dependencies.
Most of the changes were rather a mechanical fixing of changed APIs. The most challenging issue to solve was a runtime problem with the RDBMS: I reduced it to LocalDateTime fields in my JPA entities with column names “start” and “end”. As the error was a bit unclear, I looked for a solution from the latest Hibernate and Spring Data JPA release notes, but found nothing. Finally, my trusted pal from the Spring team tipped me off that the issue was most likely in the upgraded H2 database. And, yes, when I tried with a production profile (that uses MariaDB), it worked just fine. I tend to use the H2 database during development (for performance and easy development setup). Its version was upgraded in Spring Boot 2.7, and it no longer accepted “start” or “end” as a column name.
My lessons learned:
- Prepare by upgrading early (if possible).
- Upgrade one dependency at a time (if possible).
- Listen to the tips from Mr. Stephane Nicoll.
If I had taken this approach instead of skipping a minor Spring Boot release, I would easily have spotted the upgrade of the H2 database version from the 2.7 release notes.
Finally, the actual Spring Boot 3 and Vaadin 24 upgrade simply involved upgrading the versions and mechanically finding and replacing the “javax” -> “jakarta” in the classes that were depending on the JPA specification. I would even go so far as to claim that upgrading to this “big, nasty release” was easier than upgrading a Spring Boot minor or the quite straightforward Vaadin 14 to 23 upgrade. Even my rather complex Viritin add-on seems to work fine, although it is built against Vaadin 23.
To validate my lessons learned, I repeated the upgrade again in the right way to prove that the “big, nasty breaking change” isn’t that big after all:
- Upgrade to Vaadin 14->23, including dependencies (one LTS release at a time)
- Upgrade to Spring Boot 2.7 (don’t skip/postpone upgrading minors)
- Upgrade to Java 17 (from 11 to latest LTS)
- The “big” upgrade (Spring Boot 3 & Vaadin 24 pre-releases + “javax.” -> “jakarta.” find & replace using the IDE) (NOTE: No need for separate vaadin-flow-bom & vaadin-bom 23.x any more, just use latest pre-release as vaadin (-bom) version).
Try Vaadin 24 today and fill in the survey!
A good option for your actively maintained apps is to stay on the latest supported version, but periodically check compatibility with the pre-releases of upcoming versions. This way, you can clearly understand what is going to be happening soon, and you can plan your work so as to be as efficient as possible. At the same time, you are helping the projects that help you to build quality software.
If you have a chance, go ahead and try the latest pre-releases of Vaadin 24 (which you can download from this link), as well as Spring Boot 3 and other execution environments supporting the latest Jakarta EE APIs.
Even if you can't spare the time to play with pre-release libraries, we'd love it if you could take part in our related survey. It will provide us with valuable insights to serve you better during the transition period to these new versions.