GlassFish redeploys cut from 2 minutes to 5 seconds with JDWP

Most developers working with Jakarta EE applications on GlassFish know the frustration all too well. After editing just a line of Java, the cycle begins: save, rebuild the WAR, wait for undeploy, redeploy, reinitialize CDI, EJBs, JPA, JSF, and finally refresh the browser. On many projects, these redeploys average two minutes each. Multiply that by forty changes in a day and suddenly an hour is lost to logs instead of code. The irony? Most of those edits don’t need a full redeploy at all.

The JVM has supported class hot-swapping since Java 5, but accessing that capability has historically required IDEs, paid tools, or custom JVM builds. What was missing was a simple, terminal-based bridge to trigger hot-swaps without leaving the workflow. Enter gf, a lightweight tool that turns a one-line command into seamless feedback loops.

The hour lost to redeploys

Time spent redeploying isn’t just idle waiting. It disrupts focus. A recent enterprise project tracked redeploy cycles and found the average deployment took 115 seconds. Even small tweaks in method bodies, conditionals, or return values triggered the same heavy process. Over a week, that translated to hours of lost productivity. The deeper issue wasn’t the speed of redeploys—it was the frequency. Every restart resets state, clears caches, and forces context switches back to the application rather than the task at hand.

Most hot-swap solutions rely on assumptions that don’t fit universal workflows. IntelliJ Ultimate users get hot-swap, but only inside that IDE. JRebel offers impressive capabilities, but licensing costs create friction for small teams. DCEVM allows structural changes, yet requires custom JVM builds and delayed support for newer JDK releases. None of these addressed the core need: a command-line tool that works anywhere the shell does.

What worked—and what didn’t

Before building gf, three common approaches were tested:

• IntelliJ Ultimate: Its GlassFish integration supports hot-swapping during debugging, but the workflow is tied to the IDE. Some days are spent in Community Edition, others in VS Code or a terminal. The feedback loop shouldn’t follow the editor—it should follow the developer.

• JRebel: A powerful commercial solution that redefines classes on the fly. For teams with budgets, it’s worth evaluating. For contractors or small projects, the cost can outweigh the benefit.

• Plain redeploys: Reliable but slow. No magic, no surprises—just the slow march of waiting for the application to restart. It works, but it doesn’t scale with the pace of iteration.

• DCEVM: The most ambitious option, allowing method, field, and signature changes. But it demands a custom JVM, which many enterprise environments block. The tradeoff between flexibility and compatibility wasn’t worth it for this use case.

What was needed wasn’t ultimate flexibility, but the fastest path through the most common scenario: editing a method, saving, and seeing the change reflected immediately.

A terminal-first workflow emerges

The new workflow is deceptively simple:

Edit a file. Save the change. Run ./gf sync. Refresh the browser.

That’s it. No restart, no WAR rebuild, no context switch. Most daily edits—method bodies, conditionals, return values—are live within three to six seconds. For frontend assets like XHTML, CSS, JavaScript, or JasperReports templates, ./gf ui skips compilation entirely. When structural changes occur that hot-swap can’t handle, ./gf full falls back to a clean build and redeploy.

The real power isn’t the command itself, but where it runs. Any environment that can execute a shell command can trigger a hot-swap: Makefiles, scripts, CI hooks, SSH sessions, or even AI coding agents. The workflow no longer lives inside an IDE—it lives wherever the developer does.

The JVM already had the hot-swap capability. IDEs already knew how to talk to it. What was missing was a simple bridge between the terminal and the JVM’s debugging protocol.

How JDWP makes hot-swapping possible

The magic behind gf relies on technology built into every JDK: the Java Debug Wire Protocol (JDWP). The same protocol IDEs use to attach debuggers can also redefine class bytecode at runtime. No custom JVM. No plugins. Just standard functionality.

To enable hot-swapping, GlassFish starts with a debug agent:

-agentlib:jdwp=transport=dt_socket,server=y,address=*:9009

This opens a debug port the JVM listens on. Most developers use it for breakpoints, but JDWP also supports redefining loaded classes. The process is straightforward:

• Connect to the running JVM via JDWP.
• Locate the loaded class.
• Read the newly compiled bytecode from disk.
• Request the JVM to replace the existing implementation.

No restart. No new classloader. No application bootstrap. Just updated code running inside existing objects.

The core hot-swap logic in Java is surprisingly concise:

VirtualMachine vm = connector.attach(arguments);
for (Path classFile : changedClassFiles) {
  String className = classFile.toClassName();
  List<ReferenceType> types = vm.classesByName(className);
  if (types.isEmpty()) continue;
  byte[] bytecode = Files.readAllBytes(classFile);
  vm.redefineClasses(Map.of(types.get(0), bytecode));
}
vm.dispose();

Around this core sits a Bash script handling incremental compilation, Lombok support, error handling, and fallback logic. JDWP handles the actual class replacement—no magic, just leveraging existing JDK features.

There’s another benefit to using JDWP over redeploys that took time to appreciate: every redeploy creates a new application instance. Hot-swapping updates the running code in place. No context loss. No session resets. No wasted time waiting for caches to rebuild.

The missing link in development workflows

Developers today juggle multiple editors, remote sessions, and automated tools. The friction of redeploys slows iteration and breaks flow. Tools like gf don’t just save time—they change how code is written, tested, and refined. By reducing the feedback loop from minutes to seconds, the mental overhead of redeploys disappears.

The next evolution of this approach may involve tighter integration with AI coding assistants, allowing automated hot-swaps triggered by model suggestions. For now, the terminal-first workflow offers a simple, immediate solution. No licenses. No custom JVMs. Just the JVM’s built-in capabilities, exposed through a single command.

The barrier to faster iteration wasn’t the technology—it was the access. Now, with a few lines of code and a debug port, that barrier is gone.