Discussion: Java Compatibility Issue report

[CsCherrYY]

For different Gradle versions, different range of Java versions are supported. Lots of users may encounter this issue when working on a new repository. It would be very helpful if we can report this issue to users and provide the corresponding ways to fix it.

Now we can find a Compatibility Matrix in the Gradle website, this matrix is correct in general, but there are some cases. For example, we can use Java 15 and Gradle 6.3 to configure build successfully but in that matrix the first Gradle version to support Java 15 is 6.7 (Maybe the complete support since 6.7?). So, if we use this matrix for checking in advance, can we revisit it and make it more precise? With the new matrix, we can check the compatibility issue before synchronization and report to users.

Another way is to improve the current ToolingAPIStatusType, now this enum type contains several types: https://github.com/eclipse/buildship/blob/35d01caad3ab023fdd9fdf4a1b9e9c738bff7fd0/org.eclipse.buildship.core/src/main/java/org/eclipse/buildship/core/internal/operation/ToolingApiStatus.java#L36-L45

Maybe we can expand these types and add something like INCOMPATIBILITY_JAVA to show that the current Java version is incompatible with Gradle.

[donat]

It might make sense to add a different ToolingApiStatusType for the incompatibility case. At the same time, I think we should minimize the usage. How about setting up a cross-version integration test that imports a Gradle project with all combinations of Gradle + Java versions, and give the users an error message even before the actual synchronization?

[CsCherrYY]

IMO it makes sense overall, after the integration test, we can update the mentioned compatibility matrix and check version's combination before the actual synchronization.

and I just wonder about our current compatibility matrix. Just a guess, does it mean complete support? In that case I mentioned, Java 15 has been fully supported since Gradle 6.7 and in some build cases we can use Java 15 and Gradle 6.3 to build. But actually in some other cases may not. If that's true, is there a proper way to check it in advance?

[donat]

It is a bit tricky. The compatibility matrix is correct: the listed Java versions are fully supported. However, the documentation is about the command-line usage.

The Tooling API is a bit different. Some of the Gradle code needs to be loaded into the client JVM (see ToolingApiImplementationLoader). On top of that, some classes defined on the client-side may be loaded in the Gradle process (see BuildAction). The custom class loading can impose additional restrictions on the compatibility matrix.

We can test the compatibility by running a build/project sync on a Gradle project. The Java compatibility issues should consistently appear on any builds, so the target build structure should not matter much. The important part is that the Buildship implementation of task execution, model loading, and custom build actions are invoked. We should test all supported combinations of:

• Gradle versions
• Java versions running Eclipse
• Java versions running Gradle

Since the Java version running Eclipse needs to be changed, the full test coverage needs multiple passes, maybe as part of a CI pipeline.

[CsCherrYY]

Thanks for the detailed clarification, I got it. In this way, should the new status (inferred from the test result) be implemented in the Tooling API side?

[donat]

I think adding ToolingApiStatusType.INCOMPATIBILITY_JAVA would still make sense. Buildship should not even attempt to do Gradle builds/sync when it knows beforehand that the user has an invalid combination of Gradle and Java versions. We'll obtain those combinations from the test coverage.

Also, we can identify the exceptions thrown when an incompatible Java version is used and the test coverage didn't reveal the usecase (covering regressions for example).