In the previous part of this blog, I talked about the most important steps to get your project to compile with the latest Framework version.
The migration has been done through the first three steps mentioned here, and in this post, I will go over the least complicated steps of migration. Steps 4 and 5 cover the modernization of your project with the latest Framework 8 features. If you are in a hurry, you can do this later on as well, and use the new APIs only for new Vaadin code.
- Upgrade dependencies in the POM file
- Run Maven goal vaadin:upgrade8
- Upgrade Add-ons
- Upgrade non-data components
- Upgrade data components
- Back to the future
As in my previous post, prepare another bowl of popcorn, gather all your Vaadin Experts, and let’s watch the second part of the migration:
The strategy has changed a bit in this video: I’m no longer in a hurry, and I slowly upgrade small pieces of the project, making sure that it always compiles and passes tests. You can start by upgrading small components, then move on to bigger views. You can also easily hunt the deprecated warnings, from which you will find most of the old Framework 7 components that need to be migrated.
4. Upgrade non-data components [01:17]
This is simple and straightforward. Most of the APIs did not change for components that don’t use data binding, such as Layouts and Label. However, you need to pay attention to certain new default values of those components. For example, VerticalLayout and HorizontalLayout now have to space on by default, and margin settings that are most often used. Some code might need to be removed, or added, depends on what you expect the layout to look like.
5. Upgrade data components [10:51]
Fun fact: after writing the following lines, I noticed that each component or class took me exactly 10 minutes to upgrade live in the video!
I covered many use cases to migrate data components, let’s divide them into three sections:
5.1 Upgrade Grid [11:10]
Grid and all data components are now parameterized, they don’t deal with Containers anymore, and there is no Property interface anymore either. In this project, I had to convert the GeneratedPropertyContainer to use the new Grid APIs that let us easily generate columns. I also needed to specify an identifier manually for each column, to be able to refer to them later when merging Footer columns. And I found that some Grid related components have different package names, such as FooterRow, but their APIs remained exactly the same.
5.2 Upgrade LabelField (from Viritin add-on) [20:06]
Just like the core field components in Framework 8, all add-ons that deal with the new data binding APIs have changed radically. In this project, there was an old style Converter applied on the LabelField directly. When moving to Framework 8 native API, converters are configured via the new Binder class instead.
Throughout the process, I found the new data binding API to be a much simpler way to write converters and validators.
The video also shows a good example on how to automatically bind member fields of a class with a given Object, using the new Binder.
5.3 Upgrade OptionGroup [30:12]
There are now two distinct components, CheckBoxGroup and RadioButtonGroup, and in this project, I used the former one. CheckBoxGroup is for multi selection and RadioButtonGroup for single selection. There is no more need nor API to set multi select to true, but more importantly, no more unsafe casting when generating the caption or retrieving values from components.
6. Back to the future
Although not mentioned in the video, it’s now also safe to get rid of the compatibility libraries. This way your war size will be smaller and the amount of JS required by the browser is smaller. Your application will deploy faster and the initial load will be snappier for end users. To remove the compatibility dependencies, change vaadin-compatibility-server dependency to vaadin-server from your POM file. And same for possible other similar vaadin-compatibility-* dependencies.
Overall, we can see many enhancements when using the new Framework 8 components, both code wise and performance wise. Favoring well-typed java.util.collections instead of our own Container-Property-Item interfaces makes the code easier to read and write. At the same time, you’ll get a much better performing server side, regarding both memory and CPU. Although not required, it’s a good practice to upgrade all the other components to match the latest APIs and advanced data binding techniques.
Got any concerns while upgrading?
Something not working well for you?
Share your experience in a comment below!
Whether you are new to Containers or have experience, downloading this cheat sheet can assist you when encountering tasks you haven’t done lately.
Last updated: July 12, 2017