Gradle can't import my Java 8 package because it thinks it's Java 11

Help/Discuss
1

My package has this in its gradle.build:

java {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}

The project I’m trying to import it into also has this

When I try to build the project it throws this error:

Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not resolve com.saifxhatem:my-package:1.0.
     Required by:
         project :
      > No matching variant of com.saifxhatem:my-package:1.0 was found. The consumer was configured to find an API of a library compatible with Java 8, preferably in the form of class files, and its dependencies declared externally but:
          - Variant 'apiElements' capability com.saifxhatem:my-package:1.0 declares an API of a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component compatible with Java 11 and the consumer needed a component compatible with Java 8
          - Variant 'runtimeElements' capability com.saifxhatem:my-package:1.0 declares a runtime of a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component compatible with Java 11 and the consumer needed a component compatible with Java 8

My IntelliJ is set Amazon Coretto 1.8

2

Any solution to this problem?

3

Not without more information.
If the targetCompatibility would be in effect properly, it would produce a Java 8 compatible library, not a Java 11 compatible one.
But it can have various causes why it is different.
So without the build script or an MCVE, it is nearly impossible to tell.

4

I was able to solve this by blocking the *.module file in our proxy. Alternative you can go back to a version without *.module file.

5

You should do neither.
That’s a very bad idea.
The Gradle Module Metadata is like the pom.xml or ivy.xml just with a richer model that overcomes some of the limitations you have with those, like being able to properly model feature variants and attributes.

If a Gradle Module Metadata says that a library / variant is only compatible with Java 11+, you can surely trick it by blocking the GMM files and still get the library, but then it will fail at runtime with “Unsupported class version error” when you try to load the Java 11 compatible classes with Java 8.

If the GMM is actually incorrect, you can use component metadata rules to fix the GMM information in the consumer while the upstream project can fix its build to produce the correct GMM.

But just excluding and ignoring the GMM is a very bad idea and at most symptom treatment and shifting the problems to a later time where they are less obvious and harder to debug. That’s like calling invokeAndLater to “fix” strange Swing behavior or afterEvaluate to “fix” build problems.