Zipped sources are not respected

[ong-yinggao98]

Description

Zipped source files in java.project.referenceLibraries::sources are not being respected and instead, navigating to the source just gives you code decompiled by IntelliJ FernFlower. This messes up the autocomplete because the argument names will be generic things like arg0 while the source files in the zip file have properly named variables.

I am creating a module for Ghidra in VSCode using their skeleton project generation tool, which autopopulates a settings.json file with the relevant libraries and sources from your Ghidra installation path.

Environment

• Gradle 8.14.1 (GRADLE_HOME defined)
• Ghidra 11.4.2 (in /opt/ghidra/ghidra_11.4.2_PUBLIC)
• OpenJDK 23.0.2 (JAVA_HOME defined)
• Offline (see settings.json)
• Version: 1.50, 1.48 for Linux x64

Expected behaviour

• Right-clicking on a library function should show its definition as defined in the source file.
• Function autocomplete should show correct names for parameters

Actual behaviour

• Right-clicking on a library function takes you to a class decompiled with FernFlower
• Function autocomplete uses generic argument names like arg0

Steps to reproduce

1. Install Ghidra
2. Use provided settings.json
3. Open the attached project (it assumes Ghidra is in the above path)
4. In src/java/main/java/ghidraproject/GhidraProject.java:
   1. Navigate to GhidraProjectPlugin.MyProvider::createActions
   2. Hover over line 108: dockingTool.addLocalAction

      void docking.Tool.addLocalAction(ComponentProvider arg0, DockingActionIf arg1);

5. Compare with source:
   1. Extract Docking-src.zip from /opt/ghidra/ghidra_11.4.2_PUBLIC/Framework/Docking/lib/Docking-src.zip
   2. Go to docking/Tool.java and view addLocalAction @ line 157

      void docking.Tool.addLocalAction(ComponentProvider componentProvider, DockingActionIf action);

GhidraProject.zip

[fbricon]

So there are a couple issues here:

• java.project.referencedLibraries is ignored for Gradle (or other build tools) projects, it's only used when working with "unmanaged" projects (i.e. just a folder with java files). So it's sort of expected.
• Disabling gradle import ("java.import.gradle.enabled": false) SHOULD turn your Ghidra project into an unmanaged project but, unmanaged projects import is triggered when opening a java file, when no build tool files are present. Because the workspace contains a build.gradle file, the Java Language server is triggered but doesn't create the unmanaged folder.

A possible workaround (for now), is to:

• set "java.import.gradle.enabled": false in .vscode/settings.json
• rename build.gradle to build.txt
• run the "Java: Clean Java Language Server Workspace" command
• open a java file from src/main/java -> import should kick in and generate the proper project metadata under the hood
• rename build.txt to build.gradle

Now, every time you reopen the folder, you won't need to perform the above steps, the project already been imported once. You can then access the sources you configured:

On our side we can potentially provide 2 enhancements:

• automatically (re)attach java.project.referencedLibraries.sources to existing classpath containers (this needs to be done on every restart), that would allow us to manually configure sources for existing Gradle projects
• ensure unmanaged projects are properly imported/configured, even if the workspace contains a build.gradle file

[ong-yinggao98]

That explains a lot, thanks.

java.project.referencedLibraries is ignored for Gradle (or other build tools) projects, it's only used when working with "unmanaged" projects (i.e. just a folder with java files). So it's sort of expected.

I suppose this also applies to java.project.sourcePaths, which would explain why I get complaints that the Java scripts in the ghidra_scripts directory is not in the classpath despite being declared as such in settings.json, and why I cannot search for references to symbols even within the same source file.

That folder in the module is meant to house scripts written in Java that are not supposed to be compiled with the rest of the project but to be loaded as and when in a running application.

On our side we can potentially provide 2 enhancements:

• automatically (re)attach java.project.referencedLibraries.sources to existing classpath containers (this needs to be done on every restart), that would allow us to manually configure sources for existing Gradle projects
• ensure unmanaged projects are properly imported/configured, even if the workspace contains a build.gradle file

These sound helpful, and the second part will also greatly help with the problem I've just described.