Reload timing & build safety
Choose immediate or request-boundary application, and understand pause, build holds and partial failures.
Default: immediate application
The default reloadBoundary=immediate installs no request hook. A request can call old code, cross a reload, then call new code. This is the ordinary reload behavior; application-wide atomicity is not implied.
Opt in to a supported MVC request boundary
java "-javaagent:/absolute/tools/reclazz-agent-X.Y.Z.jar=reloadBoundary=request" -jar app.jarStart with the agent before MVC loads. Supported requests finish before the class batch and framework follow-up run; new requests wait during application. The agent waits up to one second to drain active requests, then admits traffic again and retains the edit for a natural idle boundary.
The one-second limit applies to draining, not total reload duration. A long framework follow-up can delay new requests for longer. An uncompleted async request or a Callable worker ignoring cancellation can defer reload indefinitely.
Native Spring 5 javax / Spring 6 Jakarta MVC dispatches include supported Callable, WebAsyncTask and DeferredResult lifetimes through servlet completion. A timed-out Callable worker remains counted until its body actually exits.
Recorded native graphs: Framework 5.3.39 / Tomcat 9.0.121 and Framework 6.1.14 / Tomcat 10.1.60, stock SapMachine 17/21, ordinary/child application loaders. A missing hook defers edits; it does not silently certify request protection. Use immediate mode for a non-MVC application.
A successful build controls admission
IntelliJ build signals hold class output while compilation is in progress. BUILD ok permits a complete captured batch only after success; a failed/cancelled build keeps it held. Newer build starts/failures invalidate an unfinished capture.
SCAN does not release a build hold. Already accepted bytes may finish while the next build is held. AutoCompile stages all modules before publishing output. These controls protect admission; they do not make framework refresh transactional.
Pause is independent of build ownership
The source baseline includes correlated RELOAD pause, resume and status commands. Wait for the acknowledgement; an old agent can ignore an unsupported command. Pause retains/coalesces newly observed work, but work already admitted can finish.
Resume does not unlock an active/failed build hold. Its acknowledgement describes admission state, not completed reload. It does not freeze application requests, stop a classloader loading new disk output, or roll back changes.
A batch can apply partially
JVM redefinition, framework metadata, singleton lifecycle and external resources are not one transaction. A later step can fail after earlier changes are already live. Read the pending ledger and verify the actual behavior before calling the save complete.
Saving the old source can reload the old implementation, but does not recover lost bean state, reverse DDL, undo imported data or restore consumed messages.
Sources & version scope
Documentation source 1.4.0 · evidence baseline 75535bd · reviewed 19 October 2026. Check your installed artifact; source features may postdate a release.