Spring Boot Developer Tools
9 CommentsLast Updated on May 11, 2019 by jt
In the 1.3.0 release of Spring Boot and new module is available called Spring Boot Developer Tools. This new Spring Boot module is aimed at improving developer productivity in building Spring Web Applications.
When you’re developing a web application in Java, or really any programming language, a common workflow is to code, compile, deploy, and then test in the browser. In scripting languages, such as PHP, there is no compile / deploy phase. The script is evaluated by the server at run time, thus negating the need for a compile / deploy phase.
In the world of Java web development, we don’t have this luxury. Our Java code is compiled down to Java byte code, then deployed to an application server such as Tomcat. The compile, deploy, test phase is a common step in the process of writing software. The longer it takes, the greater the impact it has on your productivity. I’ve seen this cycle take just a few seconds, to 30 minutes. Yes, 30 minutes! (It was a highly coupled legacy application from the early 90s – one of the most effing awful developer experiences I’ve ever encountered!)
For a long time, the Grails community has enjoyed the benefits of automatic class reloading. It’s such a pleasure coding a Java application, and only needing to save your file to have the code automatically reload in the Tomcat container – nearly instantly. This is one of the features that drew me to web development with Grails.
This feature has been missing from web development with Spring MVC for a long time. You could use a 3rd party tool such as jRebel, but at $475 annually for a license, it’s an expensive option for those coding outside the enterprise.
In the world of web development with just Spring MVC, this new feature available in Spring Boot Developer Tools has been long overdue. Way way overdue!
Reloading vs Restarting
The reloading agent from Grails is now its own project, called Spring Loaded. This takes a slightly different, but important approach than the one used in Spring Boot Developer Tools. In reloading, the agent reloads the Java class in the JVM. This avoids the need to start the Tomcat container and Spring context. But has some drawbacks. Works great for coding changes in the class itself. But change the package, or add a new class / Spring bean, and you still need to restart.
Spring Boot Developer Tools takes a different approach, it does a restart, not a reload. BUT – under the covers, it is using two class loaders. One for all jar classes in your project, and one for your project classes. Thus on a ‘restart’, only the project classes are reloaded. The 10’s of thousands of classes contained in jar files in your typical Java Spring project are not reloaded. By doing this, restarting Tomcat and the Spring context become VERY fast. Since the Spring context is being restarted, it addresses issues found with the approach used in Spring Loaded.
Use with Build Tools
The automatic restart is triggered when changes on the classpath are detected. Thus if you build with Maven or Gradle class files in the target directory will change and an automatic build will be triggered.
Use with IDEs
IntelliJ and Eclipse are the two most popular IDEs for Java development. There are some notable differences in use between the two IDEs.
Eclipse is the foundation for the Spring Tool Suite (aka STS). Development of the Spring Boot Developer Tools seems biased towards STS. Which is to be expected. Both are Pivotal products. An automatic restart in Eclipse is triggered with the save action. In Eclipse, this triggers a recompile of the change classes, which triggers the automatic restart.
With IntelliJ the process is slightly different. IntelliJ does not recompile on save, but unlike Eclipse, it does perform automatic file saves for you. IntelliJ can be configured to compile on save, but this gets disabled when an application is running. Thus in IntelliJ, you need to trigger the build manually, which will in turn fire off the automatic restart. So with the extra step, the developer experience in IntelliJ is not quite as smooth.
I prefer the developer experience with Spring Loaded, where the changes made to your *.java files will trigger the automatic restart/reload. If the Spring Boot Developer Tools had been developed the same way, the developer experience in both IDEs would be the same. Maybe the team developing the Developer Tools had a technical reason for this. Or maybe it was a choice by Pivotal to promote STS on the Eclipse platform.
This is inconvenient, but I’m not changing IDEs. The last time I tried STS, it was awful. Randomly hanging, or crashing. You just get what you pay for IMHO.
Live Reload
Another cool feature of the Spring Boot Developer Tools is the Live Reload integration. Live Reload is a browser plugin, which will trigger a page reload upon changes to the source. Thus when you change web content, the page in the browser will automatically refresh. Small improvement. But it is nice not clicking refresh in the browser all the time.
Live Reload is advertised to work for Firefox, Chrome, and Safari. I was unable to get the plugin working in Firefox – it may be currently broken with Firefox. I did get Live Reload working fine with Chrome. I did not try using it with Safari.
Free Introduction to Spring Tutorial
Remote Development and Debug
The Spring Boot Developer Tools includes support of doing remote development and debugging. You can configure automatic restarts and debugging to a remote server. Kind of a cool thing to do. But I’m not sure where I would personally ever use this feature. The folks from Pivotal have a little demonstration of this towards the end of this video.
Demonstration of Spring Boot Developer Tools
I’ve described how Spring Boot Developer Tools can improve the development workflow and improve your productivity. But a seeing a demonstration is far more effective. I recorded this video to show you the Developer Tools in action.
Conclusion
The Spring Boot Developer Tools module brings some great (and long overdue) features to developing applications with Spring. The automatic restart feature will have a positive impact on your productivity in developing web applications. Use of Developer Tools will change how you develop applications, in a good way. This is the initial release, and the time I’ve spent using the Developer Tools has been short. I saw one quirky thing, but not a show stopper. My impression is the developer tools module is ready for production use. If you’re using Spring Boot to develop web applications, it’s time to upgrade to the 1.3.0 release.
snicoll
> Thus in IntelliJ, you need to trigger the build manually, which will in turn fire off the automatic restart. So with the extra step, the > developer experience in IntelliJ is not quite as smooth.
I am really confused because I can see that statement in many places and I just don’t get it. What is the difference between saving (one shortcut) and make project (one shortcut)? Let’s say that you remap “Make Project” to cmd-s (or whatever shortcut you use in Eclipse to save). What is the difference?
jt
In IntelliJ, the file is saved automatically – anytime you exit the workspace. Thus, with Grails (Spring Loaded), no action is required. You can code, toggle over to the browser and see your changes. Minor step, but an annoyance when you’re accustomed to a smoother user experience.
snicoll
Did I misunderstood or the quote I used was comparing the Devtools experience in STS and in IntelliJ. Why are you talking of Spring Loaded now?
Caleb Cushing
To me the complaint about not compiling automatically should be redirected at IntelliJ, I personally think it’s silly that Idea won’t do this.
I think I can guess why they don’t do this with this tool though, it would make the tool require a jdk, and might even force you to use a certain one. This is silly and something I don’t like about CRaSH, it requires a JDK on a production server. It also would require more work. Why do the extra work to make IDE’s consistent, after all we choose our IDE’s for a reason.
realistically I think I might like it better that idea waits for my command, devtools wouldn’t keep up with the constant reloading.
I’m impatiently awaiting to see what devtools does on a real project, and would love to see how to integrate it without Spring Boot, because I don’t see boot coming to our project anytime soon but I might be able to make a case for devtools.
jt
My comment is more from 6+ years of development experience with IntelliJ Idea / Grails. I’m accustomed to not having to save nor build. Just toggle over to the browser and your changes are available almost instantly. Thus, the additional friction in the process is annoying.
Agree – this is a feature I’d like to see changed in IntelliJ Idea. But key point is dev tools is working against the *.class files, not the *.java files. Thus, if you’re using a text editor, over a IDE, you’d still have additional friction of building the code.
Grails (Spring Loaded) has left me spoiled.
Shame you can’t play with Spring Boot. Best thing to happen to Spring Development in a long time.
Diego Alvarez
Hi, I am starting with Spring and Gradle. I don’t use a IDE. I follow the tutorial steps from https://spring.io/guides/gs/serving-web-content/#scratch and I have a query about Livereload (I hope someone can help me). The browser should refresh it after every change on css and ‘html’ files?, or it is necessary run another cmd window and build the project again with the “gradlew build” command? I did the last thing and Livereload worked, but, it is possible that the browser refresh it after every change on css and ‘html’ files?
Geoffrey Bays
Can I use the spring boot devtools in a Spring project that does not use Spring Boot? I hope so. I may find out soon by trial and error, but just curious. Thanks.
jt
I kind of doubt it, but you might be able to hack something together. Might be easier to migrate the project to Spring Boot.