.jpg)
In the previous article we introduced dynamic tools for Swing migration to Vaadin. In this article we consider the more classic static tooling.
Static tooling works with your Swing source code, and is easier to set up because your application code doesn’t get executed as part of the transformation. Static tooling scales well to very large applications with hundreds of thousands or millions of lines of code.
Static analytical tooling
These tools enable static code analysis which is always valuable when preparing a migration. The tool parses the many Java files in your project and collects information on the Swing features your code uses, in effect letting you see all the thousands of lines of code in your application at once for each Swing method or property in use.
Once your code has been parsed, you can start asking questions that will give you insight into the work ahead of you. You can find out which Swing properties your code is accessing and which methods are invoked. For example if your code calls the method getName() on a text component in twelve different places, you know you will have to figure out the equivalent in Vaadin (hint: it’s getId()). If getName() is never used, you can safely scratch that from your list and move on to relevant questions.
You can also see which custom components you have made and how they extend the core Swing components. With the details of which API elements on which your application depends, and the high-level view of custom component use, you gain comprehensive insight to the steps needed to complete the transformation of your application.
The information this tool generates is particularly useful when involving external resources in a legacy migration project. It allows them to get up to speed quickly without requiring excessive amounts of training, even if they have never seen the source code before.
Static transformative tooling
Static tooling can go beyond analysis to automate limited transformations on the code. In some cases transformations like Swing’s getName() are straightforward to Vaadin and you can use these tools to make a copy of your source code with the transformations applied. This works especially well for view logic affecting event handling and non-visual properties. It is also suitable for when you have lots of long initializers of Panels.
Consistency, speed and correctness are the three main benefits of introducing tools to help the transformation of code. The consistency is not only to correctly identify all occurrences of the Swing API access, but to transform each one correctly to the mapped call in Vaadin. Once encoded in a tool, the transformation can be tested and re-run with improvements as often as needed with the same consistency.
For improved maintainability of the generated sources, transformative tooling works best in tandem with custom Vaadin components that provide features present in Swing but not in the core Vaadin framework. Some typical examples would be BorderLayout or radio buttons with arbitrary layouts.
Which tool is right for you
The answer is: It depends. One, both or even neither of these tools may be right for your application migration project. A lot will depend on the size of your application, how your organization sees the right balance between value and risk, and the additional budget you have available to aggressively modernize your UI to create a brand new user experience.
In general, the further you go with modernization, the harder it will be to reuse existing logic and views. Some Swing migrations combine some form of deeper modernization of those 10% of the views that need it the most with a migration of the other 90%; here Vaadin migration experts can advise you on how tooling can get you the furthest to ensure your project succeeds.
Interested in learning more?