Vaadin 7 extended maintenance started in March 2019, and Vaadin 8 in February 2022. Vaadin 23 Prime support has just started in March 2024, and Vaadin 14 goes into extended maintenance in August 2024.
So, what have we been doing lately? Let's take a look!
Taking care of the infrastructure
The build infrastructure is critical for us to keep ongoing operations running smoothly. The system naturally has technical dependencies that need to be both new enough that we can trust them and compatible enough with the specifications of the maintained version of the product. For example, Vaadin 8 supports Java 8 but should also scale to newer versions. It was originally made for IE11-era browsers but should also work with the latest Chrome, Safari, and Firefox versions.
One of the major recent updates we have made to our infrastructure is updating JDK11-based builds and newer versions of Google Web Toolkit. We still build Vaadin 8 for Java 8 compatibility and Vaadin 7 for Java 7 compatibility. This kind of maintenance work helps us keep the CI/CD pipeline reliable. From a user point of view, these are mere implementation details and should not affect the applications.
Our builds run thousands of tests each time, and the tests require occasional TLC, too. Unlike our modern Vaadin 14, 23, or 24 products, Vaadin 7 and 8 components are not web components and are more prone to slight visual changes when new browser versions are released. We need to check these and verify that no actual functionality is being broken. And it works. Since launching Extended Maintenance, we have released over 50 Vaadin 7 and 8 versions.
Another part of the infrastructure is our license checker, which we have been gradually updating in our legacy products to be the same as in our latest versions. This reduces our technical debt in the longer term and allows our delivery system to work more reliably.
Fixing bugs
Vaadin 7 and Vaadin 8 are stable products, but bugs have been reported over time. Some of these have now become established behaviors and are not being touched, but some new bugs are still being found.
Our Extended Maintenance customers have access to Expert Chat. Expert Chat discussions are one way we become aware of potential bugs, and our customers can prioritize fixing them. We also started removing deprecated Flash support this way. Most of the releases we have done have contained something prioritized by our customers.
Taking care of the security
We are working to keep our legacy products secure in three main ways.
The first is to follow our software logistics, SBOM. We update dependencies at a regular pace. We do this also when the vulnerability is a false positive, but the update is trivial. However, sometimes it is impossible to update the dependencies, due to constraints in compatibility, in which case we will provide documentation and other means to deal with it. For example, we patched the Chart add-on locally to work around security, because reworking the add-on for newer versions of the underlying library would have been too costly.
Additionally, we have our own AppSec Kit, which also supports our legacy products. This provides an easy way to see if your application has vulnerable dependencies. It will also give an annotated analysis of the dependencies via our products and indicate whether they are real threats or false positives. Some SBOM analysis tools are overeager, so we now release the framework with flattened POMs to ensure that test-time dependencies are not published.
AppSec Kit vulnerability details view. See documentation
We frequently get security-related questions about our new products. In most cases, they are just questions, but we have something to fix every now and then. We check each time whether the issue applies to our legacy products, and if it does, we proactively apply fixes to these. Actually, most of the security fixes in Vaadin 7 and 8 have been done this way.
We also monitor the security issues that our customers have reported to us, specifically those related to legacy, and act accordingly.
Deprecating and removing what is not needed
Sometimes, security is the fundamental reason to say “bye-bye” to something. A good example is that we finally completely removed Flash support in Vaadin 8. It was marked deprecated long ago, and no one uses it anymore.
One of the original promises of Vaadin 7 and 8 was that they support Internet Explorer 11. During the Extended Maintenance, we will see the gradual sunset of this. In fact, it has already begun. Eventually, our infrastructure will run completely out of capabilities to run tests on IE11, as tools no longer support it. We are no longer running all the tests. We still maintain and update our code in a conservative manner.
So, even if we eventually say that IE11 testing has ended completely and we are not officially supporting it anymore, it won’t mean that we will refactor our code extensively or deliberately use non-IE11-compatible code in future bug fixes.
Modernizing for Java 17 and Jakarta
While we keep updating our infrastructure, verifying that legacy products work in more modern environments is easier. We have two kinds of customers in Extended Maintenance support. The first one is a customer who has legacy infrastructure. This means it is not yet possible to modernize the application for a given reason. The second category is a customer who has a legacy application scheduled to be modernized later in time, as there are other applications they are working on now. In this scenario, moving the application to a newer infrastructure should be possible. We have been working gradually on this.
Nowadays, Vaadin 8 has an alternative vaadin-server-mpr-jakarta to support running Vaadin 8 alongside Vaadin 24 using the Multi-Platform Runtime product or as a standalone vanilla Servlet 6 application. We just recently also made Spring add-on version 4, which supports Spring 6 and Spring Boot 3.2. We do not have Jakarta support for all modules yet; for example, Push is not yet working on Servlet 5 and newer. We follow what our customers do and undertake developments they are interested in sponsoring.
Vaadin Directory provides a rich collection of add-ons for Vaadin, and you may find others from independent sources.
Taking care of the official add-ons
New browser versions occasionally also deprecate or even remove functionalities. Hence, we sometimes need to rework some code in our add-ons. For example, we have a Touchkit add-on for Vaadin 7. After we started Extended Maintenance, the AppCache feature was removed from browsers, and Touchkit no longer worked with these. We reworked the product to use LocalStorage instead. We have done small fixes in TestBench for a similar reason.
Final thoughts
Maintaining and modernizing Vaadin's legacy products is a continuous effort that involves updating infrastructure, fixing bugs, ensuring security, and gradually deprecating outdated features. With these efforts, we aim to provide our users with a stable and secure environment while paving the way for future enhancements. Thank you for following along with our updates and developments!
Psst... Still on Vaadin 14? Consider upgrading to Vaadin 24 for the latest updates, or if you need more time, learn more about your options.