Java debugging support — tracking issue

[debugmcpdev]

Background

Java debugging support was contributed via the @debugmcp/adapter-java package, which wrapped jdb's text REPL in a custom DAP protocol bridge. Thank you to the original contributor for the significant effort — the adapter successfully implemented session lifecycle management, source context retrieval, and stopOnEntry mode.

What worked

• Session creation and lifecycle (create → initialize → terminate)
• stopOnEntry mode (program pauses at entry point)
• Source context viewing via get_source_context
• Variable inspection and stack traces when paused via stopOnEntry

Why it was removed

Testing revealed fundamental issues with the jdb text-parsing approach:

• Breakpoints never fire in launch mode — jdb uses deferred breakpoint resolution, and the program reaches and passes breakpoint locations before jdb finishes resolving them
• Attach mode is broken — the adapter fails to establish JDWP connections reliably
• Timing races are inherent — jdb's text REPL was never designed for programmatic control; command sequencing and output parsing are fundamentally race-prone

The adapter was removed in commit d3b62a1. The original work is preserved in git history:

• a5b0982 feat: add support for java/jdb debugging
• 8c354d9 fix: align java adapter with contribution code style guidelines
• fa00174 chore: add java adapter to optionalDependencies
• ae69fd8 chore: commit unstaged Java adapter files and test report

Landscape research

There is no clean, MIT-licensed, standalone Java DAP adapter available today:

• Microsoft/Red Hat java-debug — EPL-licensed, requires the full Eclipse JDT Language Server (~200MB). Not suitable for standalone embedding.
• Eclipse LSP4J — EPL-licensed, same ecosystem dependency.
• No standalone MIT/Apache-licensed Java DAP server exists in the npm/Maven ecosystems.

Viable future paths

1. Fix the jdb wrapper

Address the deferred breakpoint timing issue and command sequencing races. The original code is preserved in git (commits above) and can be restored. Key challenges:

• Implement reliable "wait for breakpoint resolution" before issuing run
• Handle jdb's async output parsing without races
• Fix attach mode JDWP connection establishment

2. TypeScript JDWP-to-DAP bridge

Talk directly to the JVM's debug wire protocol (JDWP), bypassing jdb entirely. This is the cleanest architectural approach:

• The jdwp npm package exists as a starting point (MIT licensed, though abandoned with ~5 commits)
• JDWP is a well-documented binary protocol — implementing the needed subset (breakpoints, stepping, variable inspection) is tractable
• Eliminates all text-parsing races

3. Vendor kotlin-debug-adapter

The kotlin-debug-adapter is MIT-licensed, standalone, and speaks DAP over stdio:

• Works with JVM languages (not just Kotlin)
• Single maintainer, ~50-80MB distribution size
• Could be vendored similarly to how we vendor CodeLLDB for Rust

Contributing

Contributions toward any of these paths are welcome! If you're interested in working on Java support, please comment here to coordinate. The adapter infrastructure (adapter registry, dynamic loading, adapter policy system) is all in place — the challenge is purely on the debug adapter side.

[roofpig95008]

I get a 404 when I try to follow the link to the Kotlin adapter. A new search finds it here but that's 3 years old. :-(

I think you've made a good diagnosis of why jdb is not a suitable foundation. I will look at the other two approaches. There are other ways to do java debugging with Claude -- I think JetBrains may have their own MCP adaptor directly to their editors, and there is also this skill but I believe getting mcp-debugger to work with Java is still worthwhile.