Skip to content

VSCode doesn't show JDK Java source files when debugging JDK itself #1285

Open

Description

@wkia

I'm building and debugging the latest version of OpenJDK on Windows 11. I'd like to debug it with VSCode, however I met the following problem:

I made changes in JDK Java sources (say added System.out.println("Hello") in src\jdk.javadoc\share\classes\jdk\javadoc\internal\tool\Main.java) and built JDK using JDK19 as boot JDK. I run my Java test using my freshly built JDK. It successfully starts and prints "Hello". Then I set a breakpoint at the line after my change in VSCode, and run the test under VSCode debugger. It starts, prints "Hello", and stops on my breakpoint, and shows source code, but I can't see my changes, because VSCode loaded jdk.javadoc\jdk.javadoc.internal.tool\Main.class instead of the changed Main.java.

I suppose, the class file was taken from java.configuration.runtimes, but I have no idea how can I force VSCode to load changed sources while debugging. Although VSCode is still able to show and debug my own Java-files, and, moreover, modified native JDK code (C/C++ sources), not Java.

BTW I've got the following pop-up message when debugger starts: "The compiled classes are not compatible with the runtime JDK."

Environment
  • Operating System: Windows 11
  • JDK version: 19
  • Visual Studio Code version: 1.74.3
  • Extension pack for Java: 0.25.7
  • Java Debugger extension version: 0.47.0
Steps To Reproduce
  1. Clone openjdk repository (https://github.com/openjdk/jdk.git) and build it
  2. Make a little change in JDK's Java source file, e.g. add System.out.println("Hello") in src\jdk.javadoc\share\classes\jdk\javadoc\internal\tool\Main.java
  3. Set a breakpoint at the changed line and try to debug it with VSCode
Current Result

VSCode stops at the breakpoint, loads *.class file, which doesn't contain my changes.

Expected Result

VSCode stops at the breakpoint, loads changed *.java files and shows them in debugger.

Additional Informations

My setting.json:

"java.configuration.runtimes": [
    {
        "default": true,
        "name": "JavaSE-19",
        "path": "c:\\work\\jdk19",
    }
],

My launch.json:

{
    "type": "java",
    "name": "(java) Debug",
    "request": "launch",
    "cwd": "${workspaceFolder}",
    "mainClass": "jdk.javadoc.internal.tool.Main",
    "javaExec": "${workspaceFolder}\\build\\windows-x86_64-server-fastdebug\\jdk\\bin\\java.exe",
    "classPaths": [
        "${workspaceFolder}/build/windows-x86_64-server-fastdebug/images/jdk/lib/jrt-fs.jar",
    ],
},

Activity

  1. testforstephen commented on Jan 18, 2023

    @testforstephen
    Contributor

    Roman Marchenko (@wkia) Could you try the pre-release version of Java debugger extension? See microsoft/java-debug#463, recently we have optimized the source lookup logic to prioritize searching the project source first, then the libraries.

  2. wkia commented on Jan 18, 2023

    @wkia
    Author

    Jinbo Wang (@testforstephen) I've tried v0.47.2023011221
    Nothing's changed.
    With the configuration I provided above, VSCode still shows *.class files without my changes while I'm debugging.
    If there is any recent version, could you explain how can I try it, please?

    I also noted that if I specify source files path in java.configuration.runtimes pointing to my freshly built JDK (see below), VSCode can show my changes, but still loads *.class files, not *.java. This may be a confirmation that the plugin looks for JDK sources from runtime configuration, not workspace. Not sure if it is the solution.

    "java.configuration.runtimes": [
        {
            "default": true,
            "name": "JavaSE-19",
            "path": "c:\\work\\jdk19",
            "sources": "c:\\work\\openjdk\\build\\windows-x86_64-server-fastdebug\\images\\jdk\\lib\\src.zip"
        }
    ],
    
  3. github-actions commented on Nov 10, 2025

    @github-actions

    Hi Roman Marchenko (@wkia), I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

    Try loading your modified build output (instead of the jrt-fs.jar) so the debugger finds your changed classes and sources:

    • Add your module’s classes folder to modulePaths or classPaths in launch.json. For example:

    {
      "type": "java",
      "name": "(java) Debug",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "mainClass": "jdk.javadoc.internal.tool.Main",
      "javaExec": "${workspaceFolder}/build/windows-x86_64-server-fastdebug/jdk/bin/java.exe",
      "modulePaths": [
        "${workspaceFolder}/build/windows-x86_64-server-fastdebug/jdk/javadoc/classes"
      ],
      // remove or keep jrt-fs.jar last so it doesn’t override your classes
      "classPaths": [
        "${workspaceFolder}/build/windows-x86_64-server-fastdebug/images/jdk/lib/jrt-fs.jar"
      ],
      "env": {
        // ensure the debugger uses your custom JDK
        "JAVA_HOME": "${workspaceFolder}/build/windows-x86_64-server-fastdebug/jdk"
      }
    }
    

    • Make sure your build output and sources are compiled with the same boot JDK to avoid “compiled classes are not compatible” warnings.

    Other references to check:

    Other references with low confidence

    The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions