jbang

jbang copied to clipboard

Hi. When we specify //JAVA directive for a JBang script and run it with jbang run, obviously the version specified in the directive is used. However, when we try to edit the same script with jbang edit --open=..., it seems to no longer respect the JBang script-specific directive, but use the system (or IDE's?) default. This causes issues in syntax highlighting, autocompletion, and execution if we want to run the code via the IDE.

I saw this issue accidentally when using a Java 17 API (.toList() in the Stream class) whereas my default JDK was 15. I am using code-server, but I am not sure how it can be relevant, considering --open is pretty IDE-agnostic.

Just got bit by this as well. Was trying to use Java 17 features and can't figure out how to convince VS Code to use my JDK 17 install.

Is the JBang plugin for VS Code installed? Because for me it seems to depend on two things:

1. Have the required JDKs defined in VS Code's settings.json file, eg I have:

"java.configuration.runtimes": [
    {
        "name": "JavaSE-11",
        "path": "/home/user/.jbang/cache/jdks/11"
    },
    {
        "name": "JavaSE-17",
        "path": "/home/user/.jbang/cache/jdks/17"
    }
]

2. Click the "Synchronize JBang" button/link that appears at the top of the source file

Which IDE is this for?

There are unfortunately limits to what we can do in the project generation that jbang edit currently does. But we can do some. Depends on the IDE

That said - do try out the dedicated jbang plug-in for IntelliJ, vscode and eclipse.

They do honor //JAVA.

In an upcoming version of jbang I plan to change jbang edit to push users more in that direction as it works so much better and only use jbang edit project generation for single file editing.

Thanks for the responses.

@quintesse I do have the JBang VS Code plugin installed and have JavaSE-17 defined in the VS Code java runtimes settings. I just tried the "Synchronize JBang" option that you suggested but this didn't fix the issue.

@maxandersen This is for VS Code. I'm running jbang edit --fresh --open=code to launch. I guess you're saying the preferred mode of operating with the JBang plugin installed is to not use jbang edit at all? Does edit mode + the JBang plugin create some sort of conflict perhaps?

One thing I've noticed is that with jbang edit --fresh --open=code my workspace contains two apparently conflicting Java Projects: one with the correct JDK and one with the wrong one:

Sometimes the Java runtime version is correct as indicated at the bottom of the edit window but it's clear from the compile errors that an older compiler is being used. If I choose the Configure Java Runtime option from the ... menu under Java Projects I see this:

I guess it's still building/creating a Gradle-based project in spite of the "java.import.gradle.enabled": false setting? A bug in the VS Code RedHat Java extension(s) maybe? When I examined the build.gradle generated by JBang I did notice that it doesn't specify the required Java runtime but that's a separate issue I guess.

Maybe build.gradle shouldn't be generated at all for VS Code?

If you have a gradle project it will have priority over what is in your jbang java files.

We don't generate build.gradle in users project with jbang edit. That is done in a temporary symbolic linked project.

@maxandersen I haven't created a Gradle project, I'm speaking about the build.gradle file that was generated by JBang in ~/.jbang/cache/projects/.... Somehow this Gradle build file seems to be confusing VS Code?

To further clarify, the screenshots in my previous comments were taken from the auto-generated workspace launched via jbang edit --open=code.

That is generated when you use jbang edit.

It should not confused vscode if you are opening vscode on the project/folder your jbang script is physically in.

Maybe issue is you are opening the individual file not the folder. Do 'code .' Not 'code path to.java'