microsoft / microsoft/vscode-java-dependency
Memory exception when using java.getPackageData and more
まだ誰も着手していません。
- 主要言語
- TypeScript
- スター
- 199
- フォーク
- 105
- 平均マージ
- 1日 22時間
- マージ済み PR(30日)
- 27
説明
Hello! I am developing a VS Code extension for the static analysis of Java code. My extension is based on your extension where I have found a couple of useful commands.
However, while working with them, I ran into a few issues. One of them is critical to me, so let me start there.
- When working with large projects, calling the java.GetPackageData command causes hangs and memory leaks.
This is how I use the command:
Since not all project source files are always located in the project root directory, I use the command to get a list of paths to all elements with kind = "PackageRoot" of the project. Then I recursively get all sources (.java) from them.
In the same way, I get paths to all dependencies (.jar) of the project. I use the command to traverse all elements with kind = "Container" and get the paths to the dependencies.
The issue:
When working with a large project —in my case, this one (https://github.com/elastic/elasticsearch/releases/tag/v8.11.2) — calling the command to get the "PackageRoot" list of a single project module leads to hangs and very high RAM consumption. This causes memory exception to be thrown or the VS Code to crash.
Here is the example of a command call that causes the issue:
vscode.commands.executeCommand("java.execute.workspaceCommand", "java.GetPackageData", {kind: 2, projectUri: "file:///d%3A/Java_projects/el2/elasticsearch-8.11.2/benchmarks/");
- The "java.project.getAll" and "java.project.list" commands sometimes return different numbers of elements. Although, the only difference between the two seems to be that "java.project.getAll" returns a list of "uri" projects, while "java.project.list" returns a list of INodeData objects.
The "java.project.getAll" command sometimes returns fewer elements than "java.project.list", even though it seems like it should return the uri of all projects in the directory.
I also noticed the following differences between these commands:
- "java.project.getAll" identifies the uri of projects included via the settings.gradle file, while "java.project.list" does not. An example of including projects in the settings.gradle file:
include 'common', 'warnings'
project(':common').projectDir = new File("../../pvsjava/common")
project(':warnings').projectDir = new File("../../pvsjava/warnings")
- The "java.GetPackageData" command does not work with modules that are defined by the "java.project.list" command, but are not defined by the "java.project.getAll" command.
I would appreciate it if you could help me with the first issue. However, if you could make the "java.project.getAll" command return uri of all projects in the opened directory, and at the same time make it possible to work with these projects using the "java.GetPackageData" command, that would be great!
It would also be nice to have
a command enabling you to identify projects that contain a particular source file (.java) or directory.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、参照されている大規模プロジェクトに対する java.GetPackageData 呼び出しを再現し、その後 java.GetPackageData、java.project.getAll、java.project.list の実装またはエントリポイントを読みます。この issue はメモリ使用量、プロジェクトの検出、ソースファイルの検索にまたがっており、完了には合意されたスコープと、選択したコマンドがハングまたはクラッシュせず、一貫したプロジェクト情報を返すことの検証が必要です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java, typescript, vscode
- 領域
- developer-experience, tooling
- issue の種類
- バグ
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100