Description:
This update significantly improves the perceived speed and reliability of the jooby:run hot-reload engine by overhauling how file changes are grouped and scheduled.
1. Elimination of "Double-Waiting" (Polling Latency)
The Problem: Previously, the runner checked the event queue using a fixed-rate scheduled task (every 500ms). If a developer saved a file just a few milliseconds after a "tick," the system would wait for the next cycle, effectively forcing the developer to wait up to 1,000ms for a restart to trigger.
The Solution: We replaced the polling mechanism with a sliding-window debouncer. Now, when a file changes, a delayed task is scheduled. If another file changes rapidly (e.g., during an aggressive compilation), the timer is canceled and reset. The restart now executes exactly when the quiet period ends, eliminating artificial latency and ensuring rapid, single-batch restarts.
2. Smart Wait-Time Detection (Zero-Config Reliability)
The Problem: Different IDEs compile differently. Eclipse is notorious for writing multiple files sequentially over a few hundred milliseconds, requiring a longer debounce window (e.g., 500ms) to prevent multiple redundant restarts. However, modern IDEs and CLI tools finish almost instantly, meaning a 500ms wait feels unnecessarily sluggish.
The Solution: joobyRun now features smart compiler detection. By default, the runner looks for .classpath or .project files in the project root.
If detected (Eclipse workspace), it safely defaults to a 500ms debounce window to prevent restart loops.
If not detected, it defaults to a blazing-fast 200ms window.
Developers still retain the ability to manually override this by explicitly setting in their build configuration.
Description:
This update significantly improves the perceived speed and reliability of the jooby:run hot-reload engine by overhauling how file changes are grouped and scheduled.
1. Elimination of "Double-Waiting" (Polling Latency)
The Problem: Previously, the runner checked the event queue using a fixed-rate scheduled task (every 500ms). If a developer saved a file just a few milliseconds after a "tick," the system would wait for the next cycle, effectively forcing the developer to wait up to 1,000ms for a restart to trigger.
The Solution: We replaced the polling mechanism with a sliding-window debouncer. Now, when a file changes, a delayed task is scheduled. If another file changes rapidly (e.g., during an aggressive compilation), the timer is canceled and reset. The restart now executes exactly when the quiet period ends, eliminating artificial latency and ensuring rapid, single-batch restarts.
2. Smart Wait-Time Detection (Zero-Config Reliability)
The Problem: Different IDEs compile differently. Eclipse is notorious for writing multiple files sequentially over a few hundred milliseconds, requiring a longer debounce window (e.g., 500ms) to prevent multiple redundant restarts. However, modern IDEs and CLI tools finish almost instantly, meaning a 500ms wait feels unnecessarily sluggish.
The Solution: joobyRun now features smart compiler detection. By default, the runner looks for .classpath or .project files in the project root.
If detected (Eclipse workspace), it safely defaults to a 500ms debounce window to prevent restart loops.
If not detected, it defaults to a blazing-fast 200ms window.
Developers still retain the ability to manually override this by explicitly setting in their build configuration.