Can anyone build compose desktop under jvm 25? I ...

# compose-desktop

[ursus]

Can anyone build compose desktop under jvm 25?

I have 25 installed, JAVA_HOME set correctly

kotlin {
    jvmToolchain(25)
    compilerOptions {
        jvmTarget.set(JvmTarget.JVM_25)
    }
}

kotlin = "2.3.0"
jetbrains-compose = "1.10.0-rc02"

`./gradlew build`seems to build fine

but running it via IDE
gives me

> Task :foo.bar.MainKt.main() FAILED
Error: LinkageError occurred while loading main class foo.bar.MainKt
Error: LinkageError occurred while loading main class foo.bar.MainKt

	java.lang.UnsupportedClassVersionError: foo/bar/MainKt has been compiled by a more recent version of the Java Runtime (class file version 69.0), this version of the Java Runtime only recognizes class file versions up to 65.0

Execution failed for task ':foo.bar.MainKt.main()'.
> Process 'command '/Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1

Why? Is IDEA 2025.3 not enough?

[jw]

You are running with 21 which obviously won't work with something compiled to target 25

[ursus]

How where? Isnt that run config using gradle?

[jw]

I have no idea. You'll have to edit it and see.

[ursus]

ive no idea where its getting the 21 from..

ive set 25 in Project structure as well

[jw]

Is there a particular reason you're targeting 25? I get compiling with 25, but targeting 25 has little benefit

[ursus]

not really, I just want jvm 25's perf benefits -- I've bumped all the 21s ive seen in codebase to 25 😄

[ursus]

btw ./gradlew run launches the ui just fine (what the App run config is supposed to do but I guess its not using gradle)

[ursus]

although im noticing proguard task (for getting the release variant jar) doesnt work as well

./gradlew clean packageReleaseUberJarForCurrentOS

> Task :proguardReleaseJars FAILED
ProGuard, version 7.7.0
Unexpected error
java.io.IOException: Can't read [/Users/foo/IdeaProjects/gbar/build/libs/GitGooey.jar] (Can't process class [gitgooey/generated/resources/ActualResourceCollectorsKt.class] (Unsupported version number [69.0] (maximum 68.65535, Java null)))
        at proguard.InputReader.readInput(InputReader.java:282) ~[proguard-base-7.7.0.jar:7.7.0]
        at proguard.InputReader.readInput(InputReader.java:229) ~[proguard-base-7.7.0.jar:7.7.0]

[ursus]

I mean... is 25 too new stil?

[jw]

You need ProGuard 7.8

[jw]

But again, targeting 21 is fine. You only need to run on 25 for the performance gains.

[ursus]

btw if I decouple compile and targer versions

kotlin {
    jvmToolchain(25)
    compilerOptions {
        jvmTarget.set(JvmTarget.JVM_21)
    }
}

which is I think is this

then I get

Execution failed for task ':compileKotlin'.
> Inconsistent JVM Target Compatibility Between Java and Kotlin Tasks
    Inconsistent JVM Target Compatibility Between Java and Kotlin Tasks
      Inconsistent JVM-target compatibility detected for tasks 'compileJava' (25) and 'compileKotlin' (21).

[ursus]

You only need to run on 25 for the performance gains.

so even jvmToolchain(X) doesnt matter?

[jw]

That sets the JDK you compile with separately from your JAVA_HOME. I don't use it.

[jw]

You do need to align the Java and Kotlin compilation tasks' targets

[ursus]

I see

java {
    sourceCompatibility = JavaVersion.VERSION_21
    targetCompatibility = JavaVersion.VERSION_21
}

kotlin {
    compilerOptions {
        jvmTarget.set(JvmTarget.JVM_21)
    }
}

like this? thats it?

[jw]

Yep

[ursus]

okay just to clarify

java 25 did change bytecode (hence why it wasnt working), so presumably there is improvement, but you're saying they're not significant & not worth the hassle?

not even the compact headers? or is that not a byte code thing?

[jw]

Kotlin doesn't specialize its output bytecode for anything in 25 (or anything newer than like 17, actually)

[jw]

Compact headers are a runtime feature entirely

[jw]

You can have something compiled 30 years ago running on JDK 25 and get the benefits!

[ursus]

I see so target means basically source level stuff, language features, keywords etc?

[jw]

Kinda. The Kotlin language features aren't tied to Java bytecode version. In Java sometimes new language features will use new features of the bytecode or runtime APIs, and targeting a new version unlocks those.

[ursus]

I see thank you?

[ursus]

although proguard still seems to crap out on the 21level byte code

Can't read [/Library/Java/JavaVirtualMachines/zulu-25.jdk/Contents/Home/jmods/java.security.sasl.jmod(;;;;;;;!**.jar;!module-info.class)] (Can't process class [com/sun/security/sasl/ClientFactoryImpl.class] 

(Unsupported version number [69.0] (maximum 68.65535, Java null)))

guess I have to figure out where is the proguard version coming from