I'm trying to improve the developer experience when working with Spring Boot, especially to encourage new developers to adopt Spring Boot. The end goal is being able to offer a "git checkout + run" experience that keeps the application running and restarting whenever there are code changes, no matter the build tool, the IDE (if any), or the environment.

TL;DR;

As a developer, I start my Spring Boot application. And no matter the environment/IDE/build tool, the application will automatically restart whenever I make any code change. No configuration needed.

Achieving this experience requires two things: - recompiling the source code whenever changes are detected in the source classpath - triggering an application restart whenever changes are detected in the compiled code.

Spring Boot DevTools provides support for the second aspect, whereas the first aspect is left to the developers to configure based on the build tool, the IDE (if any), and the environment.

I'm raising this issue to suggest introducing support for the first aspect as well, and offer an application restart feature which is fully standalone and working everywhere, fully managed by Spring Boot.

I would also consider whether the logic for determining when to restart the application would benefit from being part of the Spring build system instead (and be customisable both in the Gradle and Maven Spring Boot plugins), whereas the part of DevTools applying dev-specific configuration to different Spring Boot modules could evolve based on https://github.com/spring-projects/spring-boot/issues/46368 and be included in each relevant module directly. That would have the additional benefit of not requiring an explicit dependency to enable the application restart feature.

Today, there are many challenges getting it to work. I'm putting myself in the shoes of a developer new to Spring Boot. After they check out the code, the getting started experience could be streamlined:

  1. Run the application

  2. From the CLI, they have to identify which command is needed to run the application, based on build tool, OS, and shell (many options: gradle bootRun, gradle bootTestRun, ./gradlew bootRun, ./gradlew bootTestRun, mvn spring-boot:run, mvn spring-boot:test-run, ./mvnw spring-boot:run, ./mvnw spring-boot:test-run, ./mvnd spring-boot:run, ./mvnd spring-boot:test-run...). It would be great to simply run spring dev from a CLI. That's what I'm trying to do in the Arconia CLI.

  3. From the IDE, they have to identify from which main() method to run the application (main classpath or test classpath). It would be great to work with a single entry point, as suggested in https://github.com/spring-projects/spring-boot/issues/46367.

  4. Configure the application restart features

  5. From the CLI (no IDE), they have to open a second Terminal window and use Gradle/Maven to build the project whenever they change something.

  6. From IntelliJ (both when running the app from the CLI or from the IDE), they have to manually build the project with Build -> Build Project whenever they change something.
  7. From Visual Studio Code, things are even more complicated. -- For Maven projects, the automatic restart works when using the "Language Support for Java(TM) by Red Hat" and running the application from the IDE or from the Terminal within the IDE. -- For Gradle projects, the automatic restart works when using the "Language Support for Java(TM) by Red Hat" and disabling the "Gradle for Java" extension, but only if running the application from the IDE. If the application is run from the Terminal within the IDE, the project needs to have the eclipse Gradle plugin, configured to monitor the build/ folder instead of the bin/ folder. If the "Gradle for Java" extension is enabled, the automatic reload doesn't work from either places (IDE or Terminal). The only way to get it to work is using the pre-release version of the "Gradle for Java" extension, enable the "Hot Code Replace" option in the Java Debugger extension, and run the application in debug mode from the IDE. No solution when running from the CLI.

For Gradle specifically, a workaround that can be applied in the different scenarios mentioned above is running gradle classes --continuous on a separate Terminal window, which watches the source code for changes and automatically re-compiles it (therefore, triggering Spring Boot DevTools to restart the application).

All of the above gets even more challenging when working with portable development environments (such as Devcontainers or Nix), because it's far from straightforward configuring the environment to support any possible combination of build tool + OS + IDE + shell.

  1. Iterate

Finally they can start working on the application, iterating on a solution to implement a feature or a bug fix. Based on what happened in step 2, whenever they make code changes they might need to perform some manual operations to restart the application.

All considered, it might be easier and faster to restart the application explicitly, without using the feature in Spring Boot DevTools. But that's pity, because the DevTools are really convenient and I'm glad they are part of Spring Boot, so thanks so much for them!

In case this is something that might fit the plans for the project, I'm available to help any way I can. Thanks!

Comment From: salaboy

+100 for this

Comment From: snicoll

@salaboy please add a reaction in the original issue.