Cross posting from <#C01D6HTPATV|compose-desktop> ...
# compose
a
Cross posting from #compose-desktop as related: I am trying to consume a Compose Multiplatform library I published and I am having an error on Desktop. (all other platforms work great) the error is "MenuKt has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0 How do i resolve this? do i need to change something in the library or is it something on the way i run the jvm app?
m
Use java 21 to run the application. Java 17 only supports up to format 61.
e
or publish the library with/targeting an older version of java
a
@ephemient how do i do this? is it an option on build.gradle?
You'll need the FooJay plugin to explicitly target the JBR, but i 10000% recommend that you do, and distribute it alongside your app. All other JVMs are more or less broken when it comes to UI.
a
thanks @seb. this is for the library and i am not distributing any apps. I guess i need both the java block and the kotlin options like so right?
s
Yeah so for the library you won't be bundling a JVM directly, but you should use both the java and kotlin ones yeah
As far as I remember you need both
a
Just shipped a version. waiting to be available on maven central to test it out
it works!
Why does this happen though? Do libraries always need to be compiled with the oldest Java version to make sure that people can consume it? Why use Java 17 instead of say Java 1?
Just saw that Compose Desktop has a JDK 11 requirement
e
yes libraries must target older Java in order for older consumers to use it (and the easiest way is using an older Java to build)
👍 1
you can't target Java 1
the oldest that Kotlin will target is currently 1.8 afaik
s
In Jewel we target and build with Java 17, since that's what the JBR is at (mostly)
e
it changes what features are available to Java source code but as far as Kotlin is concerned, there isn't much difference
11 adds "real" interface default methods and 17 adds "real" sealed classes iirc ("real" as in works with Java too, not just Kotlin)
a
@seb JBR is the runtime right? isnt matching the version with the runtime only important for when you distribute jvm apps?
as in, for my case when publishing a library there is no runtime, right?
s
JBR is the runtime — however, since you're also building for Desktop, you want to make sure you target the right JVM version (the desktop version is the only one for which the JDK version matters)
👍 1
m
For a general purpose library I find it a bit dangerous to use this specific
vendor
specification. You might accidentally use features which only this specific JDK contains and which are not available in any other off-the-shelf Java distribution. For building a general purpose library one should also use a standard Java JDK.
s
The JBR does have extra features but you need to use reflection/Unsafe to access them. What you really want are the big fixes (hidpi support, text rendering, etc)
m
But you only need these at runtime when you use the library, right? As far as features go. I know that the JBR, e.g., contains fonts which a standard Java does not contain. This may lead to errors without reflection.
👍 1
What you really want are the big fixes (hidpi support, text rendering, etc) Why are these fixes not upstreamed so that any JDK can benefit from them?
s
Mostly, nobody really cares. I don't think it's some conspiracy from JetBrains
😢 1
m
Could you provide some pointers to the relevant JBS issues which JetBrains has fixed in their runtime? https://bugs.openjdk.org
s
That's something you should ask JetBrains, not me
m
Of course, but it might have been possible that you know.
s
No, I'm not keeping that close of a track to what the JBR team does. I just know from experience that many things (especially in Swing, but some in Compose too) are just broken on other JVMs
e
I like building with the latest supported java, and setting the target to the earliest version my consumers would need. Is there a reason that could cause any issues? https://kotlinlang.slack.com/archives/CJLTWPH7S/p1714764236402219?thread_ts=1714752771.580799&amp;cid=CJLTWPH7S
e
yes it can cause issues, https://stackoverflow.com/a/61267496 for example
e
I think I actually saw something about that recently 🤔