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 front-end files. Both have a slightly different solution for updating the browser whenever a file changes. The front-end 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.
Vaadin Flow uses a pre-built front-end bundle by default. The only front-end 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 front-end bundle to be built, a process which might take several minutes.
frontend folder are handled by the front-end build tool / bundler. Adding, modifying, or removing a file in this folder triggers a rebuild of the front-end resources and a browser reload.
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 front-end 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).
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.