CODEWITHSUNDEEP
javagradleintellij-ideajava-homegradle-wrapper
Manish
Manish

Reputation: 1517

How to manage Multiple Java Versions for Different Gradle Projects- IntelliJ

I have two Spring Boot projects with different Java and Gradle configurations: one using Gradle 6.7 with Java 11 and the other using Gradle 8.8 with Java 17. Recently, I installed Java 17 to meet a new requirement and updated my JAVA_HOME to point to the Java 17 installation. My Java installations are located at:

/Users/test/Library/Java/JavaVirtualMachines/corretto-17.0.11/Contents/Home
/Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home

In IntelliJ, the Gradle and Project SDK settings are correctly configured to use the appropriate JDKs for each project. In the build.gradle.kts for the project with Gradle 8.8, the source and target compatibility are set to Java 17, and for the project with Gradle 6.7, they are set to Java 11:

build.gradle.kts (Gradle 8.8)

java {
    sourceCompatibility = JavaVersion.toVersion("17")
    targetCompatibility = JavaVersion.toVersion("17")
}

build.gradle.kts (Gradle 6.7)

java {
    sourceCompatibility = JavaVersion.toVersion("11")
    targetCompatibility = JavaVersion.toVersion("11")
}

The issue arises when I try to build the project with Java 11 using the Gradle wrapper from the terminal. While the build works fine for the Java 17 project using ./gradlew build, the build fails for the Java 11 project when run through the terminal, though it succeeds when running through the Gradle tool window in IntelliJ. I understand that this is because the terminal build is using JAVA_HOME, which is pointing to Java 17, while the Gradle tool window correctly uses the project-specific SDK settings.

Error:

Task :myapp:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':myapp:compileJava'.
> java.lang.IllegalAccessError: class org.gradle.api.internal.tasks.compile.processing.AggregatingProcessingStrategy (in unnamed module @0x35944de7) cannot access class com.sun.tools.javac.code.Symbol$ClassSymbol (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.code to unnamed module @0x35944de7

I'm unsure about the best practice in this scenario. Should I manually switch the JAVA_HOME for each project before running ./gradlew build, or should I pass the specific JAVA_HOME path as an argument to the Gradle wrapper or set it in gradle-wrapper.properties?

Any advice on how to handle this would be greatly appreciated.

Thanks!

Upvotes: 0

Views: 624

Answers (2)

Ammar
Ammar

Reputation: 346

You could add -Dorg.gradle.java.home flag to the command line for an example

./gradlew build -Dorg.gradle.java.home=/path/to/jdk

This solution is good if you want to build a project only once using a specific java version

Upvotes: 0

драган-јованковић
драган-јованковић

Reputation: 628

You could try doing it by overriding property in gradle.properties file, and set the path to you jdk/openjdk :

org.gradle.java.home=path-to-jdk-version

And also make sure your gradle wrapper is correctly configured.

Then try building each project.

Upvotes: 0

Related Questions