Hot Deploy & Live Reload

You can download the latest version from the JetBrains GitHub release page. Be sure to select the correct architecture. Use JetBrains Runtime to execute your application, not necessarily your IDE.

You can download HotSwapAgent from the HotswapAgent GitHub release page. You’ll need version 1.4.2 or later.

Download the JAR file and place it inside the JetBrains Runtime installation directory as lib/hotswap/hotswap-agent.jar. Use that exact file name — you’ll need to create the hotswap folder — for JetBrains Runtime to get it.

If you want to know more about the features of HotswapAgent, the documentation in the HotswapAgent webpage is a good resource.

To enable hotswapping when launching the application, you need to pass -XX:+AllowEnhancedClassRedefinition -XX:HotswapAgent=fatjar as JVM arguments — not program arguments.

If you have a Spring Boot application, you would launch the application by running the main() method of your application class. After you’ve launched it once, you’ll have a run configuration that you can edit in your IDE so that you can select the proper JDK and give the necessary parameters.

To do that in IntelliJ IDEA, select Run › Edit configurations…​. With your application run configuration chosen, you can select the JDK to use in the first drop-down. If JetBrains Runtime isn’t shown, you can select it through Select alternative JRE…​.

In the same dialog you need to click Modify options › Add VM options to be able to see the field where the JVM arguments can be defined. Then you can add -XX:+AllowEnhancedClassRedefinition -XX:HotswapAgent=fatjar.

If you have another type of application, you’ll need to pass the JVM options in the appropriate way.

With the settings in place, when you start the application in debug mode, you’ll see the following type of log output:

This indicates that HotswapAgent is loaded. Now, when you navigate to a view in your application, open the corresponding Java file in your project and make some changes — remember to compile and not only save the class if using IntelliJ IDEA. When you make changes, your view is reloaded in the browser and the changes are shown.

By default, any change in the Java code causes the application to reload in the browser. This is convenient when you make changes to the initial layout, constructors, post construct methods or similar. However, if you’re modifying the logic inside a listener, there’s no need to do a page reload for the change to take effect.

You can turn off reloading in the Vaadin Copilot in the Info panel. It can be more efficient to disable live reload, and manually reload the browser when needed. This is especially recommended when editing code related to a dialog or some other UI part which isn’t mapped directly to a URL.

IntelliJ doesn’t by default compile a Java file when you save it. If your habit is to press the compile shortcut, hotswapping works fine. Otherwise, you might want to set IntelliJ to build the project when you save. You can do that through Settings › Build, Execution, Deployment › Compiler › Build project automatically. You’ll also need to ensure that the build takes place when the application is running in debug mode. This is done through Advanced Settings › Allow auto-make to start even if developed application is currently running. Finally, through Settings › Build, Execution, Deployment › Debugger › HotSwap, Reload classes after compilation should be set to Always.

You should disable other reloading or hot swapping solutions. For example, disable the automatic restart in the Jetty Maven plugin if you’re using that. Omit or set <scanIntervalSeconds> to a value of 0 or less.

The live reload "quiet time" — which is in milliseconds since the last Java change before refreshing the browser — can be adjusted with the parameter vaadin.liveReloadQuietTime in the hotswap-agent.properties file. The default is 1000 ms. Increase this value if you notice the browser refreshing before modified Java files have been fully compiled.

Changes to some parts of the Java code, such application startup listeners, won’t have any effect until the server is restarted and the startup listeners run again. For these you need to restart the server.

If you’re using the @PreserveOnRefresh annotation, the same view instance is reused when the browser is reloaded. That means changes aren’t necessarily visible until the view is opened in another browser tab.

403FEA6B-12A3-465C-9D6D-41DA902D9884