Migrating from Vaadin 7.0 to Vaadin 7.1

This guide describes how to migrate from earlier versions to Vaadin 7.1.

Migrating from Vaadin 6

When migrating from Vaadin 6, first review Migrating from Vaadin 6 to Vaadin 7, then continue with the rest of this guide.

Migrating from Vaadin 7.0

As always with minor releases, we have tried hard to minimize the number and extent of changes that could affect existing applications you want to upgrade. However, there are a few points that must be considered, and some other changes and improvements that might be beneficial to know.

Property legacyPropertyToString

The old convention where Property toString() was used to get the value of the Property continues to cause problems. Changing this behaviour could potentially cause severe bugs that are hard to find, so instead we continue our quest to phase out this behaviour.

The behaviour can now be configured via the legacyPropertyToString (either as an init-parameter or using @VaadinServletConfiguration). The settings are:

  • “warning” = as 7.0, toString() logs warning, default when using web.xml

  • “disabled” = toString() is just toString(), does not log, default when using @VaadinServletConfiguration

  • “enabled” = legacy toString() behaviour, does not log, compatible with Vaadin 6

By default, if you are not using @VaadinServletConfiguration to configure your servlet, the functionality is the same as in 7.0, and compatible with 6; a warning is logged.

If you are using the new @VaadinServletConfiguration to configure your servlet, it is assumed that you’re creating a new project, and using getValue() instead of toString(), and no warning of toString() usage is logged.

This change will not break your application, but you should consider the options.

  1. Consider switching legacyPropertyToString mode to

  2. “enabled” if you are using toString() improperly, and do not want warnings

  3. “disabled” if you are absolutely sure you are not using toString() improperly, and do not want warnings

Converter targetType

The conversion methods in Converter now have an additional targetType parameter, used by the caller to indicate what return type is expected. This enables Converters to support multiple types, which can be handy in some cases.

This change will cause compile errors if you implement or call Converter.convertToModel() and/or Converter.convertToPresentation().

  1. Add the targetType parameter if needed

UI access() outside it’s request/response

If you have background threads/processes that update the ui (e.g long running process updating a ProgressBar), or if you otherwise update a ui from outside its request/response (e.g updating one UI from another), you should use the new UI.access() method. This ensures proper locking is done, and failing to do so might result in hard to debug concurrency problems.

To debug possible concurrency problems, it is recommended to enable assertions with the “-ea” parameter to the JVM.

This change will not break your application, but your application might already be broken; you should ensure that all ui access dome outside the request handling thread uses this new API.

Calendar included

The Calendar component, which was previously an add-on, is now included in the core framework. However, the package is new, and there are minor API changes.

This change will not break your application, but you might want to switch to the core framework version of the component.

  1. Remove the Calendar add-on

  2. Update imports to the new package

  3. Adjust for API changes

ProgressBar is the new ProgressIndicator

The ProgressIndicator component had integrated support for polling - a feature that was a bit strange, especially now with built-in polling and push support. ProgressBar is a pure visual component that is intended to replace ProgressIndicator. If you have been relying on the polling capability of ProgressIndicator, you should look at UI.setPollInterval() or enable server push.

This change does not break your application, but is deprecated, and should particularly not be used if push or UI.setPollInterval() is used.

  1. Replace ProgressIndicator with ProgressBar

  2. If you are using the polling feature use UI.setPollInterval() or enable push

isAttached() replaces session!=null

Previously you had to do an awkward getSession() != null to figure out whether or not the component (or ClientConnector to be precise) actually was attached to the UI hierarchy (attached to a session, to be precise). There is now a isAttached() method that does that. Note that the old way still works, the new way is just more explicit, clean and findable.

This change will not break your application, but if you want to clean up your code, you can look for getSession() null-checking and replace as appropriate with isAttached().

VConsole is now java.util.logging

For client-side logging and debug messages, the proprietary VConsole has been deprecated and replaced with the standard java.util.logging framework, and the messages are (by default) displayed in the completely renewed debug window.

This change will not break your application, but the old API is deprecated, and the new one has additional features (e.g log levels). To update, look for references to VConsole and replace with standard java.util.logging calls, e.g Logger.getLogger(getClass().getName()).log(“A message”).

Call init() for custom VaadinService instances

If overriding VaadinServlet.createServletService() or VaadinPortlet.createPortletService(), the new init method must be invoked for the newly-created VaadinService instance.

New features

In addition to the changes, there are a number of new features that you probably want to familiarize yourself with, such as Push and the redesigned DebugWindow.