I’m trying to use the a jvm toolchain with java 17...
# compose-desktop
p
I’m trying to use the a jvm toolchain with java 17 only for packaging the desktop app. However I can’t get that running:
Copy code
Execution failed for task ':generator:ui:checkRuntime'.
> Packaging native distributions requires JDK runtime version >= 15
  Actual version: '11'
  Java home: /Users/ph1b/Library/Java/JavaVirtualMachines/azul-11.0.15/Contents/Home
Has someone an idea, how to set the runtime of the jpackage version?
a
Are you running that from the commandline? What’s your
JAVA_HOME
set to?
t
Had a similar issue recently, cause was that I was running gradle in an older JVM. Which is basically also what Alexander is hinting at I think.
p
I can manually switch my java version to 17, but I want to make it frictionless for my devs and utilize the toolchain
r
IIRC the toolchain mechanism does not affect the JVM Gradle is running in, and you will need to set JAVA_HOME to point to a JDK >= version 15. IntelliJ has a way through the Project Structure > SDKs UI to download versions of Java from different vendors, which helps a lot though doesn't make it entirely frictionless.
p
No it doesn't. But isn't that the whole point of the tool chain? That you can specify a java version and are free to use which ever you like on your machine?
r
It removes the guess work for all the build/compile/test type tasks, which is useful, but I see what you mean. I think in a lot of situations e.g. library development the toolchain is all you need, but for jpackage you need to have Gradle running in Java 15. Is it possible to relegate packaging distributions to CI?
p
That doesn't make sense to me. In the end it's a task so you should be able to provide which java should run it
Or do I have a fundamental misunderstanding of the tool chain?
a
Gradle tasks run inside the gradle process, unless they specifically start a new one.
r
I imagine it could get awkward executing a task to update the JVM Gradle runs on while Gradle is running
229 Views