https://kotlinlang.org
Join Slack
Why is it mandatory to use Java 17 with 2.0.1?
# squarelibraries
j
Why is it mandatory to use Java 17 with 2.0.1?
h
Because we use IntelliJ as compiler platform which requires JVM 17 since 2022.2. we do try to not pass these requirements to you as consumer, see https://github.com/cashapp/sqldelight/pull/4863, bit it’s not merged yet.
👍 1
j
Will there be a quick version including it? I have seen the tests of that PR are not compiling due Java 17 too, so maybe it is not straightforward to fix it.
h
Yeah, I aware of the failings, but didn’t take a closer look yet.
j
I have checked and indeed my problem is inside the convention plugin:
Copy code
Execution failed for task ':hubdle-gradle-plugin:compileKotlin'.
> Could not resolve all files for configuration ':hubdle-gradle-plugin:compileClasspath'.
   > Could not resolve app.cash.sqldelight:gradle-plugin:2.0.1.
     Required by:
         project :hubdle-gradle-plugin > app.cash.sqldelight:app.cash.sqldelight.gradle.plugin:2.0.1
Would your change affect to the Sqldelight Gradle plugin too?
Ah yeah, it is being changed the Gradle plugin config. Sorry I was on mobile and I wasn't able to check it properly
h
The idea of the PR is to run the sqldelight compiler in a separate JVM so you don’t need to use JVM 17 to consume the gradle plugin.
👍 1
thank you color 1
m
How big of an issue is it? IIRC, Android, Spring Boot and apparently IntelliJ are 17+ now so hopefully the ecosystem should move quite fast?
➕ 1
j
Which version of AGP is forcing that? I am on the latest stable and it compiles with 11
h
AGP 8 requires JVM 17.
j
That is weird, I will recheck but I have tests passing and I don’t remember touching anything when Renovate created the PRs
h
j
Looks like it needs only Java 11 based on the message when trying to compile with Java 8
Copy code
> No matching variant of com.android.tools.build:gradle:8.2.0 was found. The consumer was configured to find a library for use during compile-time, compatible with Java 8, preferably in the form of class files, preferably optimized for standard JVMs, and its dependencies declared externally but:
          - Variant 'apiElements' capability com.android.tools.build:gradle:8.2.0 declares a library for use during compile-time, packaged as a jar, preferably optimized for standard JVMs, 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
h
Can you try gradle-api?
j
Same, Java 11
h
Interesting 🤔
m
Maybe the bytecode is Java11 with some runtime dependencies on 17. Running on Java 11 locally yields this:
Copy code
$ ./gradlew assembleDebug

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/mbonnin/git/MyApplication3/app/build.gradle.kts' line: 1

* What went wrong:
An exception occurred applying plugin request [id: 'com.android.application', version: '8.3.0-alpha16']
> Failed to apply plugin 'com.android.internal.application'.
   > Android Gradle plugin requires Java 17 to run. You are currently using Java 11.
      Your current JDK is located in /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
      You can try some of the following options:
       - changing the IDE settings.
       - changing the JAVA_HOME environment variable.
       - changing `org.gradle.java.home` in `gradle.properties`.
(same with 8.2.0)
j
That is different, I am not applying the plugin, I am only depending on it.
👍 1
m
yes
But if you depend on it, chances are at some point someone will run the AGP code (alongside yours)
So you can compile against AGP with Java11 but you need Java17 to run it looks like
Looks like it's also because of IDEA requiring 17
j
Yep, I am using Java 17 to build, but the source compatibility is Java 11. With Sqldelight the source compatibility is 17. Personally based on the timing, I would bet that requiring Java 17 on AGP was after discovering Java 17 compiles faster than Java 8/11.
👍 1
Anyway, I would think the equivalent use case would be requiring Java 17 to run the IDE plugin or applying the Sqldelight Gradle plugin but not requiring the source compatibility to Java 17.
Spring Boot requires Java 17 in source compatibility too?
m
Yay, I would say source compatibility for the spring boot runtime (blog post)
Doesn't say about the gradle plugin so maybe you can still build your app with Java 11 🙂
Anyways, I'm usually a big fan of "keep things compatible as much as possible" but in that case, I'd say Java 17 is acceptable these days
Especially if the alternative requires downloading a JVM and forking a process
j
Yeah, tbh I would use the latest, but as it is a convention plugin, I keep the minimum possible value as default. I was thinking moving to Java 21 on my machines next week as Gradle 8.5 was released 🎉
🚀 1
2 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by