Hot Deploy & Live Reload
Live reload and hot deploy together take care of automatically applying source code changes, instead of having to manually restart the server and reload the browser.
From a deployment and reloading point of view, there are two types of files in a Vaadin project: Java classes and resources, and frontend files. Both have a slightly different solution for updating the browser whenever a file changes. The frontend reloading is setup automatically out of the box while Java updates can be handled in three different ways, as described on this page.
Hot deploy and live reload are only used during development. They are disabled in production builds.
Frontend Changes
Vaadin Flow uses a pre-built frontend bundle by default. The only frontend files that are handled by the fast live reload feature are the theme files in the frontend/themes/<themename> folder. Changes to these files are automatically picked up and the browser is reloaded. Changes to any other files inside the frontend folder cause a new frontend bundle to be built, a process which might take several minutes.
If you need to actively develop the frontend files, you can enable the hot deploy mode (see Configuration Properties). In this mode all JavaScript, TypeScript, and CSS files inside the frontend folder are handled by the frontend build tool / bundler. Adding, modifying, or removing a file in this folder triggers a rebuild of the frontend resources and a browser reload.
Java Changes
Live reload handles Java classes and resources that are on the classpath.
If you have a standard war project, and have resources in the src/main/webapp folder, then these files are typically updated and deployed automatically (they’re copied inside the target folder) by your IDE when you change them. No automatic browser reload takes place when these files change.
For changes to a Java class to be deployed, they need to be saved and compiled, typically by your IDE. After the IDE compiles the class and puts it inside the target folder, live reload kicks in. This can happen via Spring Boot Developer Tools (used by default in Vaadin starter projects), which restarts the server on classpath changes, or via JRebel or HotswapAgent, both of which replace the class on the fly without restarting the server. JRebel is a commercial product, while HotswapAgent is an open source solution.
See the following sections for details on setting up the each of these options:
Only one of these technologies should be configured in a project at a time. Otherwise you might experience slow reloads, no reloads, or multiple reloads. That said, Spring Boot Developer Tools is automatically disabled if JRebel or HotswapAgent is detected.
In general, JRebel and HotswapAgent are faster as they only patch one class in memory, but some changes can’t be hotswapped. This can be caused by, for example, global state which is created only on application startup and not updated when updating a single class. For most cases inside Vaadin where global state is handled, there are plugins to both JRebel and HotswapAgent so that hotswapping still works. There can still be cases which are not handled, either in Vaadin or in your application. For example, associating frontend resources to classes using @JsModule requires a server restart.
The user session is also handled differently: as JRebel and HotswapAgent do not restart the server, the user session is preserved. With Spring Developer Tools, you lose the user session unless you ensure all parts are serializable and you turn on session serialization for development mode (see Configuration Properties).
Automatic Server Restart
As an alternative to live reload, the Jetty and TomEE Maven plugins handle automatic server restart on Java class and resource changes. These plugins don’t require you to install third-party tools, but server restarts are slower and the browser doesn’t refresh automatically.