There are several options for hot reloading. The recommended approach is to use
spring-boot-devtools
as it provides
additional development-time features such as support for fast application restarts
and LiveReload as well as sensible development-time configuration (e.g. template caching).
Alternatively, running in an IDE (especially with debugging on) is a good way to do development (all modern IDEs allow reloading of static resources and usually also hot-swapping of Java class changes).
Finally, the Maven and Gradle plugins can
be configured (see the addResources
property) to support running from the command line
with reloading of static files. You can use that with an external css/js compiler process
if you are writing that code with higher level tools.
Most of the templating technologies supported by Spring Boot include a configuration
option to disable caching (see below for details). If you’re using the
spring-boot-devtools
module these properties will be
automatically configured
for you at development time.
If you are using Thymeleaf, then set spring.thymeleaf.cache
to false
. See
ThymeleafAutoConfiguration
for other Thymeleaf customization options.
If you are using FreeMarker, then set spring.freemarker.cache
to false
. See
FreeMarkerAutoConfiguration
for other FreeMarker customization options.
If you are using Groovy templates, then set spring.groovy.template.cache
to false
. See
GroovyTemplateAutoConfiguration
for other Groovy customization options.
The spring-boot-devtools
module includes support for automatic application restarts.
Whilst not as fast a technologies such as JRebel
or Spring Loaded it’s usually
significantly faster than a “cold start”. You should probably give it a try before
investigating some of the more complex reload options discussed below.
For more details see the Chapter 20, Developer tools section.
Modern IDEs (Eclipse, IDEA, etc.) all support hot swapping of bytecode, so if you make a change that doesn’t affect class or method signatures it should reload cleanly with no side effects.
Spring Loaded goes a little further in
that it can reload class definitions with changes in the method signatures. With some
customization it can force an ApplicationContext
to refresh itself (but there is no
general mechanism to ensure that would be safe for a running application anyway, so it
would only ever be a development time trick probably).
To use Spring Loaded with the Maven command line, just add it as a dependency in the Spring Boot plugin declaration, e.g.
<plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>springloaded</artifactId> <version>1.2.6.RELEASE</version> </dependency> </dependencies> </plugin>
This normally works pretty well with Eclipse and IntelliJ IDEA as long as they have their build configuration aligned with the Maven defaults (Eclipse m2e does this out of the box).
You need to jump through a few hoops if you want to use Spring Loaded in combination with Gradle and IntelliJ IDEA. By default, IntelliJ IDEA will compile classes into a different location than Gradle, causing Spring Loaded monitoring to fail.
To configure IntelliJ IDEA correctly you can use the idea
Gradle plugin:
buildscript { repositories { jcenter() } dependencies { classpath "org.springframework.boot:spring-boot-gradle-plugin:1.5.1.RELEASE" classpath 'org.springframework:springloaded:1.2.6.RELEASE' } } apply plugin: 'idea' idea { module { inheritOutputDirs = false outputDir = file("$buildDir/classes/main/") } } // ...
Note | |
---|---|
IntelliJ IDEA must be configured to use the same Java version as the command line
Gradle task and |
You can also additionally enable ‘Make Project Automatically’ inside IntelliJ IDEA to automatically compile your code whenever a file is saved.