.jpg)
Automation can help make your migration faster and make you smarter before you start one. At Vaadin we’re working with Swing users to build tools that make the migration from Swing to Web easier to plan, cheaper, and of better quality all at once.
We have two kinds of tools that have shown to be useful - one that takes a dynamic approach and one that is static. Both tackle the problem of Swing to web application migration differently and when used properly can significantly reduce the effort and cost of web-enabling Swing applications.
In this blog post we will look at dynamic tools.
But first: Why tools though
The value you get from tooling in migrations is the speed, consistency, and low cost of applying and iteratively perfecting a set of transformation rules. Tools can apply transformations to even the largest Swing applications in a matter of hours. They can be modified to improve their usefulness and rerun with the same human effort of compiling and building an application.
Tools have an additional function in migrations of larger applications. The larger the application, the longer the migration typically takes, and the greater the chance the project team will change while the project is running. Migration tools externalize tacit knowledge in the heads of the developers on the project, make the application of the knowledge repeatable, and eliminate a dependency on point-to-point interactions to ensure a correct transfer of knowledge when new people join the team.
Dynamic tooling
Vaadin dynamic tooling takes the furthest step in innovating beyond traditional code conversion tools. Vaadin dynamic tooling extracts screen composition information from the Swing applications while they are running.
The dynamic tools will connect to the JVM of your running application so you can capture the visual component tree of your views as they appear to the user. These captures are serialized into an inventory, and from this inventory we create compact HTML and can calculate an optimized CSS rule set.
This approach is especially useful for Swing applications that were made with dynamic compositions that rely on factory patterns and hand-written code, as opposed to more static view initialization blocks that Swing WYSIWYG tools generate.
Swing, with its flexibility in design patterns and emphasis on JavaBeans, makes no distinction in syntax between property setting during or post initialization. Swing property setter invocations related to visual attributes can fill one of at least three different purposes:
- Relationship to the brand
General application look and feel for compliance with company branding conventions
- Relationship to the view
To indicate the component has a certain fixed role inside a view, for instance to indicate help available, field read-only or modifiable, or a required input field
- Relationship to the data
To indicate visually what the status is of the data inside a component, for instance if there are unsaved changes, input validation failures, or if it contains the keyboard focus
Especially if your Swing applications contain a lot of hand-written code, you may find it time-consuming to make HTML designs and CSS for your web application while properly distinguishing between these three scenarios during the migration. Vaadin dynamic tools make this task easier.
HTML designs are not required when migrating to Vaadin but they are useful due to their compatibility with Vaadin’s declarative HTML syntax (Vaadin 8) and Polymer templates (Vaadin 10 and beyond) and they serve as a model of the user interface. They offer a compact representation of how the view looks when it is newly initiated, and once you get a collection of these designs that describe your application, it is easier to rationally plan your use of clean CSS than if you approached the migration one screen at a time.
The tool works through deep custom serialization of the JVM heap at the time each extraction was made of the Swing application, and the result is a collection of data files and images that can be processed further. This eliminates the dependency on manual screenshots or mockups and makes sure that invisible and disabled fields are correctly extracted, and that the LayoutManager and parent of each component is properly identified.
Because the tool performs a custom serialization, it works even if your Swing views and their properties are not serializable as such. The custom serialization isn’t limited to Swing, and works also for any custom components you may have made that extend Swing, AWT, QT Jambi, or any other framework.
Interested in learning more?