'Type Pattern' being reported as an error even though Java source level is above 16

[JojoFR1]

While modding for the game Mindustry, I noticed that I get the error The Java feature 'Type Patterns' is only available with source level 16 and above - Java(4195411) while doing 'Type Pattern' even though the sourceLevel is set to 17 (see linked mod template repository down below).
The explanation for this error might be because targetLevel is set to 8 and the --release 8 argument is also added. If you are wondering why it is like that... I do not know but one of the dependecy, jabel (https://github.com/Anuken/jabel), is supposed to make the Java 17 features be retro compatible with Java 8.

Environment

• Operating System: Windows 11
• JDK version: OpenJDK Runtime Environment Temurin-22.0.1+8 (build 22.0.1+8)
• Visual Studio Code version: 1.91.1
• Java extension version: 1.33.2024072008

Steps To Reproduce

1. Clone https://github.com/Anuken/MindustryJavaModTemplate
2. Add (anywhere) some simple Type Pattern cast (e.g. below)

Object test = 2f;
if (test instanceof Float f) {

}

3. Try to build using gradle jar or ./grawled jar, it should be succesful.

Current Result

The 'Type Pattern' are being reported as an error, even though it builds fine (and run fine in-game too, but I don't expect you to bother trying.)

Expected Result

The 'Type Pattern' to not be reported as an error, or at least be able to ignore the error.

Additional Informations

Due to the specific situation, it might not be possible to fix this, so maybe adding the option to ignore error is a possible way if it's possible for you to do.

[rgrunber]

This might be related to eclipse-jdt/eclipse.jdt.core#2741 . It was fixed about 7 hours ago so maybe we can update and see if this fixes the issue.

[rgrunber]

I'm not seeing this behaviour on 1.33.2024072008 or the newer pre-release. I do see a warning about : The compiler compliance specified is 17 but a JRE 1.8 is used . @snjeza , are you able to reproduce what's described here ?

If you click on the curly brace tooltip on the bottom right corner of the editor, and then hover over the "Configure Java Runtime" link, do you see something like :

Specifically that the compliance is JavaSE-17 and that a JRE 1.8 JDK is used for it ?

[JojoFR1]

I updated to 1.33.2024072408, which did not fix the issue. About the Java Runtime I got this:

My Java Runtime settings currently look like this:

"java.configuration.runtimes": [
    {
        "name": "JavaSE-17",
        "path": "D:/Tools/jdk/jdk-17.0.11+9",
        "default": false
    },
    {
        "name": "JavaSE-21",
        "path": "D:/Tools/jdk/jdk-21.0.3+9",
        "default": false
    },
    {
        "name": "JavaSE-22",
        "path": "D:/Tools/jdk/jdk-22.0.1+8",
        "default": true
    }
],

[snjeza]

I'm not seeing this behaviour on 1.33.2024072008 or the newer pre-release. I do see a warning about : The compiler compliance specified is 17 but a JRE 1.8 is used . @snjeza , are you able to reproduce what's described here ?

@rgrunber I can't reproduce the issue. I have tried Java LS 1.32.0 and pre-release.
My settings:

    "java.configuration.runtimes": [
        {
            "name": "JavaSE-21",
            "path": "/usr/local/jdk-21",
            "default": false
        },
        {
            "name": "JavaSE-22",
            "path": "/usr/local/jdk-22",
            "default": true
        },
        {
            "name": "JavaSE-1.8",
            "path": "/usr/lib/jvm/java-1.8.0-openjdk",
            "default": false
        },
        {
            "name": "JavaSE-11",
            "path": "/usr/local/jdk-11.0.8+10.hotspot/",
            "default": false
        },
        {
            "name": "JavaSE-13",
            "path": "/usr/local/jdk-13.0.2"
        },
        {
            "name": "JavaSE-14",
            "path": "/usr/local/jdk-14"
        },
        {
            "name": "JavaSE-17",
            "path": "/usr/lib/jvm/java-17-openjdk",
            "default": false
        },
        {
            "name": "JavaSE-15",
            "path": "/usr/local/jdk-15.0.1",
            "sources": "/usr/local/jdk-15.0.1/lib/src.zip",
            "default": false
        },
        {
            "name": "JavaSE-16",
            "path": "/usr/local/jdk-16.0.1",
            "sources": "/usr/local/jdk-16.0.1/lib/src.zip",
            "default": false
        },
        {
            "name": "JavaSE-19",
            "path": "/usr/local/jdk-19",
            "default": false
        },
        {
            "name": "JavaSE-20",
            "path": "/usr/local/jdk-20",
            "default": false
        }
    ],

[cypher256]

I don't know if it's a bug or a feature, but the error will be resolved by doing the following:

build.gradle

// options.compilerArgs.addAll(['--release', '8'])
   options.compilerArgs.addAll(['--release', '17'])

[snjeza]

@cypher256 Could you try to add

"java.gradle.buildServer.enabled": "off",

to your settings.json?

[JojoFR1]

I don't know if it's a bug or a feature, but the error will be resolved by doing the following:

build.gradle

// options.compilerArgs.addAll(['--release', '8'])
   options.compilerArgs.addAll(['--release', '17'])

As far as I know the Java 8 backwards compatibility is required for it to work on Android. I will ask about it to have clear answers.
I will also test later but I can't at the moment, it's almost 5AM.

Update: The developer did confirm it's to support 32bits and Android.

[cypher256]

@snjeza

"java.gradle.buildServer.enabled": "off",

The error is gone!

[rgrunber]

@jdneo , could this be some incompatibility between how the gradle build server performs the build and buildship ?

[JojoFR1]

It has been 2 weeks so far since the last comment, is there any news/idea on the problem?

So far the settings (that was previously suggested) to disable the gradle build server does work on removing the error, I wonder does it impact anything important/useful if it's disabled?

[rgrunber]

You can read more about the Gradle build server at https://devblogs.microsoft.com/java/announcing-the-build-server-for-gradle-open-source-repository/ . It should play nicely with the vscode-java extension. If java.gradle.buildServer.enabled is enabled, then the build server will handle Gradle projects, and if disabled, vscode-java's embedded Gradle support will handle it. It seemed to me like this issue was a case of the build server performing incorrectly, hence why disabling it seems to resolve the issue.

[jdneo]

@jdneo , could this be some incompatibility between how the gradle build server performs the build and buildship ?

TBH, I don't know who should be blamed for this issue. I think the behavior that gradle build server sets the source & target level to 1.8 is correct. Due to that --release 8 is added into the javac options. The document of javac says:

Note: When using --release, you cannot also use the --source/-source or --target/-target options.

This is the reason why both source and target level is set to 1.8 from gradle build server.

What's more, the source level should not be higher than the target level, which is a javac limitation: gradle/gradle#8009 (comment)

I don't know why gradle can compile the java code successfully 🤔

[jdneo]

I can bring this question to our sync meeting with Gradle.

Instead of disabling gradle build server, another workaround is that you can change the language level via the project setting page.

1. Click the Java status bar item
   
2. In the dropdown, click Open Project Settings
3. In the Compiler section, change the bytecode version to sth like 17
   
4. Apply the change

[jdneo]

Ok, I understand why the project can compile the new java language features with --release 8.

Yes, it's due to the annotation processor jabel. If I comment out that line, it will fail. With it, the compilation succeeds.

That makes me thinking that whether we should take the release argument in compilation option into consideration, or just simply takes the source compatibility that user sets.