Repository navigation
Description
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
- Clone openjdk repository (https://github.com/openjdk/jdk.git) and build it
- 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
- 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
testforstephen commentedon Jan 18, 2023
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.
wkia commentedon Jan 18, 2023
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.runtimespointing 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.github-actions commentedon Nov 10, 2025
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
classesfolder to modulePaths or classPaths in launch.json. For example:• 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
Issue When the debugger stops at a breakpoint, it loads the source in target/classes, not src/java #823 “When the debugger stops at a breakpoint, it loads the source in target/classes, not src/java”
• Similar source-lookup behavior in Maven projects; suggests customizing source paths
• When the debugger stops at a breakpoint, it loads the source in target/classes, not src/java #823
Issue JDK source files not opening in the editor when stepping to JDK classes (unknown sources in the call stack). #1437 “JDK source files not opening in the editor when stepping to JDK classes”
• Describes debugging against
jrtand missing source attachment for JDK classes• JDK source files not opening in the editor when stepping to JDK classes (unknown sources in the call stack). #1437
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!