The detected jdk version is not compatible with current gradle version

[yuyully]

Gradle for java: v3.17.0

The detected jdk version is not compatible with current gradle version

Repro steps:

1. Make sure there is JDK 21/16 in your local machine and JAVA_HOME is not JDK 21/16.
2. Don't set gradle import java version in vscode settings

Clone and open https://github.com/apache/lucene.git : The detected jdk is 17 but actually 21 is required.

Clone and open https://github.com/SpongePowered/Mixin.git : The detected jdk is 16 but actually it reports an error with jdk 17. (java home=17)

[jdneo]

@Tanish-Ranjan Would you like to take this one?

[Tanish-Ranjan]

@jdneo Sure I will look into it.

[yuyully]

No idea which jdk version is used for gradle project if there is no this notification message.

Set local JAVA_HOME=1.8, open https://github.com/py4j/py4j/tree/master/py4j-java, there is no such notification and gradle java home is shown as 17. I don't know which jdk version is used for this project. It would be better to print related information in the log.

[yuyully]

project: https://github.com/RoaringBitmap/RoaringBitmap.git

Local java home = 17, gradle wrapper of this project is 6.9.4 which is not supported with jdk 17, it doesn't get a compatible jdk version and reports an error as below.

[Tanish-Ranjan]

The issue here arises from probe building the project to determine compatibility of the selected JDK. GradleBuild model is not always able to determine if the JAVA_HOME version used for the project will successfully build the project. This should be acceptable as there might be a plugin which imposes its own jdk requirements in which case the only possible way to determine the correct JAVA_HOME version is to build the project.

There won't be a build failure if the JDK specified in the extension settings is compatible. Build Server tests the default configuration and only tries to switch to a different JDK if the default configuration is faulty.

Since this was supposed to be an accessibility feature, we could:

1. Notify the user of the JDK being used for building the project. I would suggest instead of showing a notification, integrating this with the vscode-gradle extension. A selector on the status bar could show the selected JDK and allow users to change it from there.
2. Bring parity between the .log file and the output window to prevent any confusion. I could look into this.

I will do some experiments and see how we can improve the current method of selecting a JDK without building the whole project when possible.