Migrating from Vaadin 7.0 to Vaadin 7.1

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:

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.

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().

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.

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.

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.

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().

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”).

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