microsoft / microsoft/vscode-java-debug
VSCode doesn't show JDK Java source files when debugging JDK itself
まだ誰も着手していません。
- 主要言語
- TypeScript
- スター
- 591
- フォーク
- 429
- 平均マージ
- 1日 9時間
- マージ済み PR(30日)
- 19
説明
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",
],
},
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、レポートに示されている launch.json javaExec と classPaths、および java.configuration.runtimes 設定から始め、Java デバッガーが JDK クラスのソースをどのように選択するかを追跡します。記載されている OpenJDK Main.java の変更で問題を再現し、デバッグ時に互換性のないクラスビューではなく、変更後の Java ソースが表示されることを確認します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java, typescript, vscode
- 領域
- devtools
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100