microsoft / microsoft/vscode-java-dependency

Memory exception when using java.getPackageData and more

Đang mở
#808 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Ngôn ngữ chính
TypeScript
Star
199
Fork
105
Merge trung bình
1 ngày 22 giờ
Pull request đã merge (30 ngày)
27

Mô tả

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.

  1. 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/");

  1. 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.

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu bằng cách tái hiện lệnh gọi java.GetPackageData đối với dự án lớn được tham chiếu, sau đó đọc các phần triển khai hoặc điểm vào của java.GetPackageData, java.project.getAll và java.project.list. Issue này bao quát việc sử dụng bộ nhớ, việc phát hiện dự án và tra cứu tệp nguồn; để hoàn tất cần có phạm vi đã thống nhất, cùng với việc xác minh rằng các lệnh được chọn không còn bị treo hoặc gặp sự cố và trả về thông tin dự án nhất quán.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
java, typescript, vscode
Lĩnh vực
developer-experience, tooling
Loại issue
Lỗi
Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
25/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.