Accelerate Java Microservice Iteration with Quarkus Live Coding

Problem: Long Feedback Loops in Java Microservice Development

When building a REST service in Java, the typical cycle is: edit a source file, rebuild the application, restart the server, and then hit the endpoint to see the change. Even with Gradle or Maven incremental builds, a full restart can take several seconds, especially with many modules or heavy extensions. This latency slows feature experiments, debugging, and the overall developer experience.

Quarkus Dev Mode: Fast‑Feedback on the JVM

Quarkus Dev Mode (started with ./mvnw quarkus:dev or ./gradlew quarkusDev) addresses this by running the application in a special JVM mode:

• It starts with a trimmed classpath that contains only the classes needed for the current run.
• The file system is watched for changes; when a source file or resource is modified, Quarkus recompiles only the affected classes.
• Compiled classes are reloaded into the running JVM via a custom classloader, so the application restarts in under a second.
• Extension processing (e.g., CDI, RESTEasy, JSON-B) is re‑executed on the fly, ensuring that generated bytecode and configuration validations are up‑to‑date.
• Because the code still runs on the HotSpot JVM, you can attach a debugger, set breakpoints, and profile normally.

In practice, this means you can edit a resource method, save the file, and immediately see the new response without any manual restart.

Concrete Example: Hot‑Reloading a Greeting Endpoint

1. Create a new project (if you don't already have one):

   mvn io.quarkus:quarkus-maven-plugin:create \
     -DprojectGroupId=org.example \
     -DprojectArtifactId=demo \
     -DclassName=org.example.GreetingResource \
     -Dpath=/hello
   

2. Start dev mode from the project root:

   ./mvnw quarkus:dev
   

   Output will show the application starting on http://localhost:8080 and a message like Quarkus started in dev mode (build time: 1.2s).

3. Edit the resource (open src/main/java/org/example/GreetingResource.java) and change the returned string:

   @Path("/hello")
   public class GreetingResource {
       @GET
       public String hello() {
           return "Hello, Quarkus!"; // change this line
       }
   }
   

   Save the file. In the terminal you should see a short recompile banner, e.g., Recompiling 1 class(es) in 0.3s.

4. Verify the change without restarting the server:

   curl http://localhost:8080/hello
   

   The response should now be Hello, Quarkus!.

5. Live‑reload configuration – open src/main/resources/application.properties and add:

   quarkus.http.port=8081
   

   Save again. The console will indicate a reload, and curl http://localhost:8081/hello will return the greeting on the new port.

Trade‑Offs and Limitations

• Performance not representative: Dev mode disables many JVM optimizations (e.g., JIT tuning) and skips native image analysis. Benchmarks run in dev mode will usually be slower than a production build.
• Extension compatibility: Some extensions rely on static native‑image analysis (e.g., reflection registration with @RegisterForReflection). If you plan to compile to native, you may need additional configuration that dev mode does not enforce.
• File‑watch overhead: On large multi‑module projects the file‑system watcher can consume CPU and memory. You can limit watched directories with the property quarkus.live-reload.watched-directories.
  • Example: quarkus.live-reload.watched-directories=src/main/java,src/main/resources
• Stateful changes: If your application holds long‑lived state (e.g., in-memory caches), a hot reload will reset that state. In such cases you may need to restart manually or use a custom reload strategy.

How to Verify Dev Mode Is Working Correctly

• After starting dev mode, the console should display a line similar to Quarkus started in dev mode (build time: 1.3s) and a prompt like Press Ctrl+C to exit.
• When you edit a file, look for a brief Recompiling message followed by Reloading application and a short rebuild time.
• Use curl or a browser to hit the endpoint and confirm the updated behavior.
• Attach a debugger (e.g., IntelliJ or VS Code) to the running JVM and set a breakpoint in the updated method to ensure that the new bytecode is executed.

Practical Takeaway

Quarkus dev mode is a powerful tool for reducing inner‑loop latency in Java microservice development. By running on the JVM, it preserves full debugging and profiling capabilities while offering near‑instant hot reload of code, templates, and configuration. Keep in mind that dev mode is not a performance proxy and may hide native‑image‑specific issues. Use it for rapid experimentation, then run a full production build (e.g., ./mvnw package -Dnative) to validate runtime behavior.

Next Steps

• Explore quarkus:dev options like --debug to enable remote debugging on port 5005.
• Experiment with quarkus.devservices to automatically start databases or messaging brokers during dev mode.
• Consider using the quarkus.devmode.reload-on property to fine‑tune which resources trigger a reload.