Limitations of MPR

Using MPR in your project to port a legacy application to Vaadin Flow has some known limitations. This is the current list of limitations - keep in mind that it can change over time as new features are implemented.

It’s possible to add a legacy component to a Flow layout, but not a Flow component in a legacy layout

The LegacyWrapper class and the HasLegacyComponents mixin interface only work for adding legacy components or views in a Flow layout, and not the other way around.

Custom UIs are supported, but not building the application in there

Custom legacy UIs can be used to host configuration settings, but can’t be used as a layout. You need to convert your UIs layouting to be in components, and then wrap them with a LegacyWrapper and add them to a Flow layout. Custom UIs can be used as long as they extend MprUI, the root navigation target is annotated with @LegacyUI(*.class) and you don’t use UI.setContent();.

Multiple UIs are not supported

Also because of the need of the MprUI, multiple legacy UIs are not supported. They need to be converted to a legacy layout and then wrapped in a LegacyWrapper for Flow to use them.

Custom legacy VaadinServlets are not supported

MPR has a special servlet (called MprServlet) that knows how to map each request to the appropriate framework. This makes legacy VaadinServlets unusable in an application controlled by the MPR. If you need some custom functionality, you can use the VaadinServlet provided by Flow instead. See Flow documentation on Dynamic content for details.

Only Vaadin 7.7.14+ and Vaadin 8.6.0+ are supported

The 7.7.14 and 8.6.0 releases introduced the changes needed for MPR to work with Vaadin 7 and Vaadin 8 respectively. Versions before 7.7.14 and 8.6.0 are not supported.

CDN and FETCH are not supported for the widgetset mode

When using MPR you can not use CDN for the widgetset. This means that the configuration

  • <vaadin.widgetset.mode>cdn</vaadin.widgetset.mode> or

  • <vaadin.widgetset.mode>fetch</vaadin.widgetset.mode>

should be removed from the pom.xml.

Runtime changing of the legacy theme is not supported

when using the @MprTheme annotation, the legacy theme is set at startup time, and can’t be changed dynamically after the application has been started.

No ViewScope in Flow Spring add-on

The Vaadin 14 Spring add-on doesn’t have a feature comparable with @ViewScope, so when using MPR with Spring, that scope is not supported.

UI.getCurrent() is no longer automatically inherited into the spawned thread

This code no longer works when running with MPR:

button.addClickListener(event -> {
    new Thread(() -> {
        UI.getCurrent()
            .access(() -> Notification.show("Hello from thread"));
    }).start();
});

The workaround for this is to store UI.getCurrent() already in the click listener into an effectively final variable that the thread can use:

button.addClickListener(event -> {
    UI ui = UI.getCurrent();
    new Thread(() -> {
        ui.access(() -> Notification.show("Hello from thread"));
    }).start();
});

PhantomJS is not supported

The PhantomJS project is not maintained anymore, and Flow doesn’t officially support it. Old Vaadin projects that rely on PhantomJS should use alternatives when using MPR, such as headless browsers.

Java 8+ is required

Since the application managed by the MPR is a Flow application, it requires Java 8+ runtime to work.

Old browsers are not supported

Browser support for MPR applications is based on the running Vaadin platform version. For Vaadin 14, those include Internet Explorer 11 (with transpilation), and evergreen browsers (the latest versions of Chrome, Firefox, Opera, Safari and Edge). For Vaadin 15 and newer, IE11 and Safari versions older than 13 are not supported anymore, unlike with Vaadin 14.

Vaadin Board 1.1.0 is not supported

Since Vaadin Board 1.1.0 requires Polymer 2 and Vaadin 14 requires Polymer 3, Vaadin Board is not compatible with Vaadin 14 and cannot be used as a legacy component. It works if Vaadin 14 runs in compatibility mode.

Z-planes compatibility with Vaadin 14

Certain components like popups, windows, and tooltips are rendered on different z-indeces. Vaadin 7/8 uses different approach with z-planes than Vaadin 14. Therefore, for example, if you have a modal Vaadin 14 Dialog, which has a Vaadin 8 ComboBox inside, the popup of the Vaadin 8 ComboBox will open under the Vaadin 14 Dialog’s modal curtain. Other similar glitches may occur and solving them requires code refactoring.

Views with a lot of component might be slower to render

MPR applications usually have roughly the double amount of styles compared to applications that use only one Vaadin version. This will slow down the computed style calculation of the view, which is part of rendering the view, since every element has to be checked against a bigger number of selectors. This is likely to affect especially views that have a huge number of components visible at the same time. It is possible to optimize this by reducing the total number of selectors, their complexity, or the number of visible components.