Vscode-java: Java Debugging

[gorkem]

[scgm11]

are you planning on support debug and remote debug for java?

[fbricon]

Yes, eventually. But our resources are pretty strained. Contributions are welcome :-)

[ntt2k]

I am junior developer and want to contribute my time to make this feature happen:

• debug and remote debug for java
• possible support for popular web framework like Spring / Spring MVC / Spring Boot

Can any Senior developer here point me to the resource that I can learn and start to 'bootstrap' to implement these features into plugin 'redhat-developer/vscode-java' ?

[gorkem]

I do not think we should host the tooling for all Java frameworks on this extension. I would rather concentrate on enablers such as #111 (#5) for other extensions to implement framework specific tooling. Perhaps you can contribute to this repository or have your own extension that utilizes APIs from this one for Spring boot.

For debugging we will be using debug protocol directly from our Java server. I think the first step is to create the bindings for the debug protocol. Protocol is defined as a json schema, perhaps you can get started with creating binding from the schema. You can see an example of POJO generation from JSON schemas on the server repository. If you decide to tackle the POJO generation, please file an issue specific for that to discuss details.

[fbricon]

Matching issue on the server side: https://github.com/eclipse/eclipse.jdt.ls/issues/157

[bmingles]

Curious if any work has been done on the debugging feature?

[fbricon]

Current work on the debugger can be found under :

• https://github.com/vscjavaci/vscode-java : for the vscode extension
• https://github.com/vscjavaci/eclipse.jdt.ls : for the jdt.ls+debugger server

As I go over the code and test stuff out, I'll post/update remarks here:

With the current state of the WIP, I was able to:

• start a Main class in debug
• add breakpoints, that are respected by the debugger
• advance step by step
• step into classes from the classpath

However, some critical things are missing from an MVP standpoint

• variables are not displayed
• hence they can't be modified
• no standard or error output for the program being run
• you can not attach the debugger to a remote java process
• you can not set breakpoints into classes from classpath (i.e outside workspace)
• when stepping into a class from the classpath, it's not open properly, as you have no java support for that class (no documentation on hover, no ctrl+click navigation)

Other critical aspects, that'll have to be dealt with sooner rather than later. I have no doubt they'll be adressed eventually, just listing them here for track keeping:

• classpath doesn't respect Maven (or Gradle) scopes. For now all classpath from the current project is used for runtime execution
• Java 9's modulepath is not covered yet, as expected

[more to come]

[fbricon]

@akaroml I still can't see variables with the latest code from vscjavaci master branches

[akaroml]

@fbricon Sorry for feeding inaccurate info during the sync meeting. The pull request for working with variables was actually rejected by me for design issues and we are reworking it.
It's good that you provide this check list for MVP. We'll run through it and share more info later.

[ansyral]

hi, @fbricon about this one:

classpath doesn't respect Maven (or Gradle) scopes. For now all classpath from the current project is used for runtime execution

do you mean that we should expose compile classpath? i tested a simple Maven project, and it could debug well, could you give me more hints how it doesn't work? Thanks~

[fbricon]

@ansyral if you add junit to your project with the test scope, then when executing a main class, it should not be available at runtime. Try running this:

    public static void main(String[] args) {
        try {
            Class.forName("org.junit.Test");
            System.err.println("Junit is on the classpath");//SHOULD NOT HAPPEN AT RUNTIME
        } catch (ClassNotFoundException expected) {
            System.err.println("Junit is NOT on the classpath");
        }
    }

If you run that in Eclipse, it'll work as expected, because m2e adjusts the available classpath of the launch configuration.

[akaroml]

We just released the Java Debug Extension for Visual Studio Code. This extension adds debugging support to the language server. You can find the new extension here:
https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-debug

@fbricon @gorkem please see if we can close this issue.

[fbricon]

Closing as the debugger is available from https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-debug