(Feature Request) Add support for JDT Debbuger and Test Infrastructure?

[dasTanmoy0096]

This is a repost from redhat-developer/vscode-java#4453, re-posting here for more visibility. But just to re-iterate the same,

Today, the VSCode Java suite of extensions use only the JDT's Language Services. Debugging, Testing Infrastructure, and other miscellaneous abilities (such as project view) are done by Microsoft's Helper extensions.

While I have no disdain for the Microsoft extensions, I believe we should unify the experience across the full Eclipse IDE and VSCode. That is, the default debugger and test runners should be the one that is natively used by the Eclipse IDE, communicated to VSCode via the Debug Adapter Protocols and Test Protocols.

Why, you might ask? Mainly to unify the experience. Most VSCode Extensions do the same:

Microsoft's own C# Dev Kit uses the same debugger and internal engine as Visual Studio for debugging and running tests.

Oracle's Java Extension uses the same Debugger and Test Infrastructure as NetBeans, communicated to VSCode via LSP and DAP.

Also, the Java Debugger by Microsoft doesn't use DAP, it uses its own custom solution, and the Java test extension produces garbage outputs when running tests, rather than having parity with CLI.

Would be neat to have one unified experience across both the native Eclipse IDE, and VSCode.

Thank You.

[mpalat]

This looks like a good ask. @SougandhS Since you are quite an active committer on JDT.Debug and straddling into JDT.LS as well, can you do some initial investigation here? @jjohnstn - can you please assign this to @SougandhS ? Also, please let us know your thoughts on this

[SougandhS]

This looks like a good ask. @SougandhS Since you are quite an active committer on JDT.Debug and straddling into JDT.LS as well, can you do some initial investigation here?

Will check Manoj 👍

[angelozerr]

Also, the Java Debugger by Microsoft doesn't use DAP, it uses its own custom solution, and the Java test extension produces garbage outputs when running tests, rather than having parity with CLI.

I don't understand why you are saying that, when I see https://github.com/microsoft/vscode-java-debug/blob/6322dc0f330d734fe0caaed099a65852166e1ff1/src/javaDebugAdapterDescriptorFactory.ts#L9 it uses DAP from vscode on client side, right?

[dasTanmoy0096]

Also, the Java Debugger by Microsoft doesn't use DAP, it uses its own custom solution, and the Java test extension produces garbage outputs when running tests, rather than having parity with CLI.

I don't understand why you are saying that, when I see https://github.com/microsoft/vscode-java-debug/blob/6322dc0f330d734fe0caaed099a65852166e1ff1/src/javaDebugAdapterDescriptorFactory.ts#L9 it uses DAP from vscode on client side, right?

Not sure about the file you linked, perhaps they use some custom logic from the extension (client) side to make it DAP compliant from VSCode PoV, but there has been long-standing issues, albeit minor, of non-conformance with DAP as Microsoft's Debugger doesn't use LSP4J.debug. Such as this: microsoft/java-debug#444 (comment)

Moreover, I feel like porting Eclipse's battle tested Debugger to DAP would unify experience between both the native IDE and other LSP/DAP clients. Even NetBeans has done it, and they have used LSP4J.debug yet JDT Language Server/Extension does not (the irony).

There are also long-standing issues with Microsoft's Test Runner where running tests with it produces garbage output in the test window, perhaps I can replicate that and show if necessary. In such cases I really feel porting a battle tested IDE's solution might have been better than creating a new solution altogether.

Although I am aware if efforts are indeed made for this, that might lead to a lot of re-engineering. I am willing to help as well, although I am aware there are much better engineers in RedHat and IBM.

[datho7561]

My understanding (perhaps it's wrong) is that java-debug uses jdt.debug under the hood already. For instance, take a look here: https://github.com/microsoft/java-debug/blob/main/com.microsoft.java.debug.plugin/META-INF/MANIFEST.MF#L15

[dasTanmoy0096]

My understanding (perhaps it's wrong) is that java-debug uses jdt.debug under the hood already. For instance, take a look here: https://github.com/microsoft/java-debug/blob/main/com.microsoft.java.debug.plugin/META-INF/MANIFEST.MF#L15

I looked into it, and it does re-use the AST-evaluation stuff and thread/stack frame watching, but the rest of the debugger event loop/breakpoints/stepping/hot code replace is all handled by non-JDT/Microsoft's own code rather thant JDT.Debug.

[wenytang-ms]

Thanks for the detailed write-up — a few factual clarifications, since some of these are already being discussed above.

1. "The Java Debugger doesn't use DAP / uses a custom solution."
   It is a DAP server.  AbstractProtocolServer  speaks the standard DAP wire format ( Content-Length  framing,  seq , request/response/event messages), and the client side attaches through VS Code's native  DebugAdapterServer  in  javaDebugAdapterDescriptorFactory.ts  (this is the same file @angelozerr linked). From VS Code's perspective it is a fully protocol-based DAP adapter.

2. "It doesn't use LSP4J.debug."
   Correct — and that's the key distinction.  org.eclipse.lsp4j.debug  is one Java binding of the DAP schema; not depending on it does not make an adapter non-conformant. java-debug simply generates its own DAP types. Where there are genuine DAP-conformance bugs (e.g. the one linked at java-debug#444), those are fixable individually and are the right unit of work — not a reason to re-architect the whole adapter.

3. "It's a new solution rather than reusing Eclipse's debugger."
   @dasTanmoy0096's read above is accurate. The debug core ( com.microsoft.java.debug.core ) is built directly on JDI ( com.sun.jdi ) — the JDK's standard Java Debug Interface, which is the same low-level API Eclipse's own debugger sits on. Breakpoints, stepping, the event loop and Hot Code Replace are Microsoft's own JDI-based implementation. The one place it reuses  org.eclipse.jdt.debug  is AST-based expression evaluation ( JdtEvaluationProvider  →  ASTEvaluationEngine ), which is why the  Require-Bundle  only appears in the plugin module. So it's better described as a DAP server on the same JDI foundation Eclipse uses, reusing jdt.debug specifically for expression evaluation — not a from-scratch rewrite that ignores Eclipse's infrastructure. Whether to reuse more of jdt.debug is a legitimate design discussion, but it's a layering choice rather than a lack of reuse.

4. "The test runner produces garbage output."
   This one is a real, reproducible bug and thank you for raising it. The JUnit runner communicates over a control protocol ( %TSTTREE ,  %TESTS ,  %TRACES , …) that  JUnitRunnerResultAnalyzer  parses. Today every line — including those recognized control frames — is echoed verbatim to the results view, which is the noise you saw.

[testforstephen]

I don't fully understand the motivation behind this feature request. In my view, reimplementing the debugger and test runner would be high effort with limited additional value. The existing vscode-java-debug and vscode-java-test extensions already reuse core components from jdt.core, including the JUnit execution and evaluation engines. These extensions have been used for years and are verified by lots of users.

They are open source projects. If you think there are issues blocking your use, you can open issues there and contribute to them.

[datho7561]

I agree with Jinbo, I don't see the value in rewriting the debugger or writing a new debugger.

[angelozerr]

Not sure about the file you linked, perhaps they use some custom logic from the extension (client) side to make it DAP compliant from VSCode PoV,

I can confirm that it is a DAP server. the only thing that you need to do is to prepare a proper launch configuration by using JDT.LS, see https://github.com/angelozerr/mcp-languagetools/blob/e3f7c432a64865593a6c28639e78035c932d7500/extensions/jdtls/src/main/java/com/redhat/mcp/languagetools/extensions/jdtls/dap/JavaDebugServer.java#L81 but once you have the proper launch configuration, everything follows DAP specification.

[akaroml]

@dasTanmoy0096 @mpalat @SougandhS we ack the issues towards the current UX of debugging and testing and will improve. @wenytang-ms will follow with work items.

However, we don't see clear benefit rewriting any of the the components. The reported problem can be fixed without rewriting.

[mpalat]

@dasTanmoy0096 @mpalat @SougandhS we ack the issues towards the current UX of debugging and testing and will improve. @wenytang-ms will follow with work items.

[adding a gist of internal discussion with @akaroml here:]

Idea was to provide some features of Eclipse JDT debugger that were missing in the VSCode avatar. From the issue description, it was pointing to a rewrite. However, as the discussion unfolded, we understand now that the rewrite is not necessary. That said, the original intent remains: ie of providing some useful features present in Eclipse JDT Debugger but missing in JDT-LS equivalent.

@SougandhS will raise some of these features as enhancement issues to JDT LS in sometime and these feature requests can then be taken individually for feasibility with the existing infrastructure and taken forward opportunistically.