JDK API compatibility should match the sourceCompatibility option

[rosberglinhares]

I have only Java 12 installed in my machine. Even if I set the sourceCompatibility and targetCompatibility to Java 8, the following code still compiles:

boolean b = "".isBlank();

PS: the isBlank method is only available in JDK 11.

Wouldn't it be better if the JDK API matched the sourceCompatibility option?

Adding the following line in the org.eclipse.jdt.core.prefs file solves the problem:

org.eclipse.jdt.core.compiler.release=enabled

This uses the new Java 9 --release option to compile for a specific VM version.

[donat]

Buildship updates the compiler properties as follows:

• Eclipse's compiler compliance level and source compatibility is updated to Gradle' sourceCompatibility
• Eclipse's generated .class file compatibility is updated to Gradle's targetCompatibility.

I've created a sample project, added the "".isBlank(), and adjusted the project.sourceCompatibilityandproject.targetCompatibility. When both set to 11 (and above), the project compiles. When both set to 10`, a marker shows up with a compilation error.

If you experience a different behavior, then you might have a local problem. Do you use the latest Eclipse version? Or maybe the JDK you are trying to use is not recognized by Eclipse (check Preferences > Java > Installed JREs).

[rosberglinhares]

Hi @donat ,

I created the project using gradle init and selecting Kotlin as the build script DSL. After, I imported the project in Eclipse selecting Existing Gradle Project. The project is compiling for me. To get a compiler error, I have to add that line in the org.eclipse.jdt.core.prefs file. Here is some information about my environment:

Versions:

• Eclipse IDE for Enterprise Java Developers Version: 2019-09 R (4.13.0) Build id: 20190917-1200

  

  

• Buildship: Eclipse Plug-ins for Gradle 3.1.2.v20190903-1802

• Gradle 5.6.3

  Build time: 2019-10-18 00:28:36 UTC Revision: bd168bbf5d152c479186a897f2cea494b7875d13

  Kotlin: 1.3.41 Groovy: 2.5.4 Ant: Apache Ant(TM) version 1.9.14 compiled on March 12 2019 JVM: 12.0.2 (Oracle Corporation 12.0.2+10) OS: Windows 10 10.0 amd64

• java version "12.0.2" 2019-07-16 Java(TM) SE Runtime Environment (build 12.0.2+10) Java HotSpot(TM) 64-Bit Server VM (build 12.0.2+10, mixed mode, sharing)

Java Compiler window before I changed the org.eclipse.jdt.core.prefs file:

Java Compiler window after I changed the org.eclipse.jdt.core.prefs file:

Files:

• build.gradle.kts

  plugins {
      java
      application
  }
  
  java {
      sourceCompatibility = JavaVersion.VERSION_1_8
      targetCompatibility = JavaVersion.VERSION_1_8
  }
  
  application {
      mainClassName = "JavaApp.App"
  }
  

• .settings\org.eclipse.jdt.core.prefs

  eclipse.preferences.version=1
  org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.8
  org.eclipse.jdt.core.compiler.compliance=1.8
  org.eclipse.jdt.core.compiler.source=1.8
  

• \src\main\java\JavaApp\App.java

  package JavaApp;
  
  public class App {
      public static void main(String[] args) {
          boolean b = "".isBlank();
      }
  }
  

[donat]

What happens if you install a proper Java 1.8 JDK in the Installed JREs section?

[mquan86]

Confirm the same bug.

In my case:

• Install JDK 11
• Eclipse 2021-06
• In build.gradle, I use "application" plugin and has declaration for compatible to Java 8 only:

  sourceCompatibility = '1.8'
  targetCompatibility = '1.8'
  
  compileJava {
      options.release = 8
  }
  

In Java file, if I use "".isBlank(), eclipse compile normal and doesn't give any error. I noticed same as rosberglinhares mention above that in eclipse setting, the project Java Compiler doesn't have option --release enabled.

I test similar with Maven and it works pretty well, which it sets that flag correctly and Eclipse will trigger compile error for "".isBlank()

So seems that Buildship's bug that didn't set that setting for Eclipse correctly.

[urferr]

any news on this issue? I noticed the same behaviour with Eclipse 2023-12 and buildship 3.1.8. The release option is never checked in the project properties after new project import.