Java Application Modernization Made Faster

Modernizing a business-critical Java application can mean rewriting it from scratch, replacing it with a purchased application, or transforming it to extend its lifespan. Regardless of the approach, one thing remains constant: you must first understand the application you're replacing.

If you've worked on your application for years, you might intuitively know its structure—how many views it has, how much code is copy-pasted, or how it relies on third-party libraries. But when starting a high-budget, high-risk modernization project, intuition isn’t enough. You need solid data to guide decisions:

How many components and libraries does your app use?
Were standard libraries customized, and are those customizations still relevant?
Are there outdated or unnecessary APIs?

For years, Vaadin’s Migration Assessments have provided developers with detailed reports and expert analysis to answer these questions. But, not every project needs a full assessment right away. Sometimes, teams just need a quick, high-level overview to gauge the complexity of the work ahead.

That’s where Vaadin’s free Modernization Toolkit Analyzer comes in—making it easy for you to take the first step toward Java application modernization.

More than just an analyzer – A complete Java application modernization Toolkit

The Modernization Toolkit is our solution for transforming and updating legacy Java applications to modern web frameworks. A key part of this toolkit is the Analyzer, which scans your code to identify dependencies on outdated libraries and estimates how much of the modernization process can be automated.

In addition to the free Analyzer, the Modernization Toolkit includes:

Dragonfly Transpiler – Handles the heavy lifting by refactoring application source code.
Feature Pack – Extends the Vaadin Flow framework with useful features from other frameworks and libraries.

The Analyzer is available in two variants: a Maven plug-in (hosted in the Vaadin directory) and an Eclipse plug-in. Both offer the same core functionality, but the easy-to-use Eclipse version comes with more advantages:

1) No modifications needed: Analyze your application without changing pom.xml, unlike the Maven variant, which requires adding vaadin-addons as a plugin repository.

2) Works across multiple projects: The Eclipse plug-in operates at the workspace level, allowing analysis across multiple parent POMs, multi-module setups, and even Gradle projects, whereas the Maven plug-in is restricted to individual POM files.

3) More user-friendly: The Eclipse UI simplifies analysis—just click through the options, no risk of typos.

Even if Eclipse isn’t your main IDE, setting it up for this analysis can save time and effort.

Psst...Discover Vaadin 24.5’s latest Modernization Toolkit updates in this expert-led webinar. Watch now to see how the components accelerate Java application modernization!

What information does the Analyzer produce?

The Analyzer provides insights into three key areas:

Application size: Measures lines of code, the number of Maven projects, and the number of Java compilation units.
Library exposure: Quantifies the application’s exposure to libraries by analyzing references resolving to one or more package namespaces.
Dependency coverage: Estimates how much of the application’s dependencies can be handled by Dragonfly and the Modernization Toolkit.

The Modernization Toolkit Analyzer can be used to check the exposure of an application to any Java dependency, but the primary use case is web-enabling desktop Java applications or upgrading older Vaadin applications running on Vaadin 7 or 8.

How does the Analyzer identify dependencies?

The Analyzer identifies dependencies by matching package prefixes. This pattern-based approach ensures that the tool knows what to look for when scanning the application.

For example, the default pattern used is com.vaadin, which corresponds to the most frequent use case for applications built on Vaadin 7 or 8. By default, the Analyzer would find an occurrence of com.vaadin.ui.TextField but it would not find an occurrence of org.vaadin.viritin.fields.EmailField for this reason.

Customizing patterns for broader analysis

You can extend or override the default pattern to suit your application’s specific needs:

Eclipse plugin: Use the dialog interface to define or modify patterns.
Maven plugin: Specify patterns explicitly using the -Dpatterns argument.

To search for multiple patterns, use a semicolon as a delimiter. For example, specifying com.vaadin;org.vaadin.viritin allows the Analyzer to detect both the Vaadin 7 TextField and the Viritin EmailField.

Note: Matches are detected only if the declaring type is in binary (non-source) form. If your project contains source files with declared classes in the com.vaadin namespace, they will be skipped during analysis. Dragonfly applies the same transformation to these files as it does to the rest of the application code, ensuring consistency.

How the Analyzer report differs from a Migration Assessment report

The Analyzer evaluates application coverage just like the Dragonfly Transpiler, identifying elements within the specified packages. Most real-world cases fall into two categories: method/constructor invocations and types.

Method and constructor invocations

For method invocations, we closely follow the Java compiler’s logic for overloading and overriding. When an invocation occurs, we resolve the class where the method is declared. If the class belongs to a package that matches the pattern, the Analyzer counts it (and Dragonfly would handle it). Otherwise, the invocation is ignored.

Constructor invocations are counted similarly—if the instantiated class matches the pattern or if super resolves to such a class, it is included in the analysis.

Type analysis

For types appearing in the code, analysis can be more complex since they can exist in various syntax contexts, including extends clauses in type declarations, result clauses in method declarations, local variables, cast expressions, and more. In rare cases, certain types may be converted differently depending on their context (e.g., if abstract classes are transformed into interfaces). However, they will always be flagged as occurrences.

Types referenced in the code are taken at face value and counted only if they match the specified pattern, regardless of any indirect dependencies in their inheritance hierarchy. For example, MyTextField remains MyTextField, even if it extends Vaadin TextField.

What about custom components and wrappers?

Customizing Java frameworks is common in Java applications, and the Modernization Toolkit ensures that your application code’s interaction with custom wrappers remains unaffected.

If you have access to the wrapper source code, Dragonfly will handle the transformation. As a result, your application will continue interacting with the wrappers as before—keeping your code easy to test, maintain, and extend without additional modifications.

Get started today!

Uncover valuable insights about your codebase and take the first step in Java application modernization with the free Modernization Toolkit Analyzer. Choose your preferred option and follow our step-by-step guides:

Eclipse plugin: Start here -->
Maven plugin: Start here -->

Need help mapping out your successful path to Java application modernization? Contact us with any questions, leave a comment below, or start a conversation in the Vaadin Forum.

Your first step to Java application modernization