No Java runtime version displayed for non-invisible project created under the jdt.ls workspace

[fbricon]

Some context
I'm trying to get JBang scripts work OOTB in VS Code. Since the classpath dependencies are coded right in the Java file, I use a similar mechanism to invisible projects to create a Java project under the jdt.ls workspace, that is then augmented with informations gathered from the JBang directives in the original file. This is based on jbang-eclipse. The jdt.ls integration is currently living on my fork. Finally, the VS Code Java integration can be found at https://github.com/fbricon/vscode-jbang, one can install a CI build of the vscode-jbang.vsix from the latest release page.

Now.

When I open a folder containing a JBang script, say hello.java:

///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS com.github.lalyos:jfiglet:0.0.9
//DEPS org.slf4j:slf4j-api:1.7.32
//JAVA 17
import com.github.lalyos.jfiglet.FigletFont;

class hello {

    public static void main(String... args) throws Exception {
        System.out.println(FigletFont.convertOneLine(
                "Hello " + ((args.length > 0) ? args[0] : "jbang")));
    }

}

After opening the file, the Java Runtime version is not displayed. It should show JavaSE-17 (or whatever is matching the //JAVA version comment in the file.

I have a strong feeling Invisible project detection conflicts with other projects under the jdt.ls workspace. Chance are, we'll need to identify invisible projects differently, i.e. by adding them an invisible project specific nature.

[rgrunber]

Hold on. I'm not convinced the problem is on the JDT-LS side just yet. There might be some thing we need to fix with eclipse-jdtls/eclipse.jdt.ls#2178 (CC @jdneo ) but here's what I'm seeing :

I have latest vscode-java (from sources) and your vscode-jbang pre-release installed, and can confirm the Java version (from the status provider, among other things fails to show up). For background, the runtime status bar provider shows when the opened (active) file is owned by a project. This is roughly when some project path is a prefix of the opened file URI.

In my case the file path is : '/home/rgrunber/sample-projects/jbang-example/hello.java'
The project path is : /home/rgrunber/.config/Code/User/workspaceStorage/dabc0a2a4417e0b9bdcb3f2dbd2aeaa2/redhat.java/jdt_ws/hello.java/_/

Of course those never match, so the status provider fails to display since it doesn't query the project for the additional info.

Note that the project list comes from java.project.getAll delegate command from JDT-LS. The interesting part is https://github.com/eclipse/eclipse.jdt.ls/blob/86a86d3c72c1b13cab7a616b9868d4cb9b71bf64/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/commands/ProjectCommand.java#L219 . Basically, /home/rgrunber/.config/Code/User/workspaceStorage/dabc0a2a4417e0b9bdcb3f2dbd2aeaa2/redhat.java/jdt_ws/hello.java/_/ is a real folder on my filesystem, which overrides the behaviour of the virtual link (_) at /home/rgrunber/.config/Code/User/workspaceStorage/dabc0a2a4417e0b9bdcb3f2dbd2aeaa2/redhat.java/ss_ws/.metadata/.plugins/org.eclipse.core.resources/.projects/jbang-example_b14f3f98/.project .

So is vscode-jbang generating this _ somewhere as part of import ?

[jdneo]

So is vscode-jbang generating this _ somewhere as part of import

Yes, JBang importer generates the _ folder, and then links the JBang script file to that folder. From the .project file of the JBang project:

<linkedResources>
    <link>
        <name>_/Hello.java</name>
        <type>1</type>
        <location>//C:/Users/xxx/Desktop/jbang/Hello.java</location>
    </link>
</linkedResources>

Looks like the ProjectUtils.getProjectRealFolder() cannot handle such case correctly. - when a file instead of a folder is linked to the project.

I can think of two solutions to this problem:

1. Delegate the project real path calculation to the importer that the project belongs to.
2. Send a request to the server to ask needed information when the client-side cache is missed.

[fbricon]

FYI I might also add a mode where the folder, instead of the file, is linked.