fix(java): route every launch through the mtime-aware JDI bridge resolution (#646)

[debugmcpdev]

Summary

buildAdapterCommand resolved the compiled JDI bridge with a pure existsSync walk and only fell back to ensureJdiBridgeCompiled() — the one function carrying the isClassStale mtime guard — when no JdiDapServer.class existed at all. After editing JdiDapServer.java (or a checkout that touched it) every session silently ran the old class.

• packages/adapter-java/src/utils/jdi-resolver.ts — new ensureJdiBridge(): JdiBridgeStatus ({dir, sourceFile, stale, recompiled, error}); ensureJdiBridgeCompiled() is a thin wrapper over it, so the existing API keeps working. A fresh class costs two stats; a stale class is recompiled; a stale class that cannot be recompiled is returned with the reason (javac missing, or the compiler's first stderr lines — javac's output is now captured instead of inherited into the proxy worker's stdio). JDI_BRIDGE_DIR is treated as an explicit override: never compared against the in-tree source, never rebuilt. isJdiBridgeStale() is the no-compile probe. An install that ships only the class is never stale (stat failure → not stale, unchanged).
• java-debug-adapter.ts — buildAdapterCommand always calls ensureJdiBridge(), logs a recompile, and warns with the reason when it has to run a stale class. validateEnvironment adds a JDI_BRIDGE_STALE warning (valid stays true — the launch will recompile).
• java-adapter-factory.ts — validate() surfaces the same warning plus details.jdiBridgeStale, so mcp-debugger doctor shows it.
• Not touched, deliberately: the hard-coded -cp java/out fallback in adapter-policy-java.ts (only reached when no adapterCommand is supplied) is a separate concern.
• Tests: jdi-resolver.test.ts now mocks statSync (the mtime branch was unreachable in the old suite) and covers fresh / stale+javac / stale+no-javac / stale+compile-error / JDI_BRIDGE_DIR / class-only install; new jdi-bridge-staleness.test.ts covers the adapter and factory wiring with the resolver mocked. Changelog fragment changelog.d/646.fixed.md.

Verified live

touch packages/adapter-java/java/JdiDapServer.java, then:

• mcp-debugger doctor → java row ⚠️ warn, fix line: JDI bridge source is newer than the compiled class at …; the next launch recompiles it (javac required)…
• start_debugging examples/java/HelloWorld.java with a breakpoint on line 24 → the session log carries the JDI_BRIDGE_STALE warning from validateEnvironment and then [JavaDebugAdapter] JDI bridge source was newer than the compiled class; recompiled into …/java/out; the class mtime moved past the source; the breakpoint hit and get_local_variables returned x=10, y=20.

Fixes #646

🤖 Generated with Claude Code

https://claude.ai/code/session_01SNhNB42Y55cgsknYTQb2Bm

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!