microsoft / microsoft/vscode-java-debug
VSCode doesn't show JDK Java source files when debugging JDK itself
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 591
- Forks
- 429
- Ø Merge
- 1 T. 9 Std.
- Gemergte PRs (30 T.)
- 19
Beschreibung
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",
],
},
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginnen Sie mit launch.json javaExec und classPaths sowie der im Bericht gezeigten Einstellung java.configuration.runtimes, und verfolgen Sie anschließend, wie der Java-Debugger die Quelle für JDK-Klassen auswählt. Reproduzieren Sie das Problem mit der aufgeführten OpenJDK Main.java-Änderung und überprüfen Sie, dass das Debugging den geänderten Java-Quelltext statt der inkompatiblen Klassenansicht anzeigt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- java, typescript, vscode
- Bereich
- devtools
- Issue-Typ
- Bug
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 35/100