https://kotlinlang.org logo
Join Slack
Powered by
Hello :wave: I'm a bit lost with all JVM option t...
# library-development
a
Hello 👋 I'm a bit lost with all JVM option that we can setup in a kotlin library. #Koin is working with Java 8 sources/target compat. I don't see any need to change it, apart following Android ecosystem AGP. Do you see any strong advise to not stay in Java 8 sources/taget compat?
m
Even on Android I’m not sure what you get by targetting java 11 or 17
Note you probably want to use 
--release
instead of 
sources/target
compatibility, see https://jakewharton.com/kotlins-jdk-release-compatibility-flag/
I’m sticking with Java 8 for now.
a
ok interesting 👍 thanks @mbonnin
yeah, I'm thinking trying to keep java 8 compat as much as I can. AGP compat is less a problem for library authors I guess
m
Java 8 + Kotlin 2.0.0 is my combo
a
I was reading some perfs improvements on Java 11 and Java 17 ... but it kills retro compat
m
AGP compat
Not sure I follow. AGP needs to be run with Java17 but can use dependencies using Java 8 bytecode
a
AGP needs to be run with Java17
yes
it's for building on local dev. No impact on produced lib
m
I see. Then my combo for building is latest Gradle + latest java and compatibility flags. See https://blog.alllex.me/posts/2023-11-03-liberal-library-tooling/
👍 1
👀 1
some perfs improvements on Java 11 and Java 17
If this is improvements on the runtime, like garbage collection, it shouldn’t matter for libraries
👍 1
j
The main idea is that, with a higher target bytecode level, the Kotlin compiler can theoretically make use of more efficient bytecode. In practice, I believe there is currently only the following: • using 9+ allows string concatenation via invokedynamic • using 14+ allows compiling data classes to JVM records • using 17+ generates the 
PermittedSubclasses
class file attribute for interop with Java sealed classes But more could be added later of course.
🙏 3
⭐ 2
e
My rule of thumb is as low as possible for libraries and as high as possible for applications.
👍 1
j
For my personal OSS libraries, I have been using 11 for quite some time now. Java 8 is technically deprecated. I'm not too knowledgeable about the Android ecosystem, but I believe even old-ish Android SDK versions support Java 11 now.
m
On Android, D8 can work with Java 17 bytecode IIRC, I’ve sucessfully done that. But it’s not very clear what I gained by doing this.
a
Java 8 is still used widely on Android OS until Android 8/9 https://apilevels.com/
it's 90-95% of the market right now
m
But D8 can desugar dex Java 17 bytecode
a
you mean that it could retrocompat to all people using java 8 apps ?
m
Yep
It’s not “desugar”, it’s more “dex” but yea, you can have Java 17 bytecode and D8 can transform that into dex code that runs on older Android versions
Android doesn’t run java bytecode
a
ok then, intersting. is there any interest to have KMP in java 8 then? this is the remaining part if potnetially, android part can be compiled in java 17 🤔
m
You might still have JVM consumers (Spring servers, compose Desktop, etc...). They might or might not be ready to switch to java 17
Spring requires java 17 IIRC, compose Desktop I don’t know
Although it’d be silly to run state of the art compose Desktop on java 8... But maybe someone has an old CLI running on java 8 somewhere, who knows 🤷
😆 1
😅 1
a
fyi sample apps generated from kmp.jetbrains.com are setup with java 11
nothing specified when using only compose desktop app 😛
weird stuff on my side. We are using stately that is compiled in java 17. But our codebase is in java 8 ... shouldn't we have integration issue then?
m
Have you tried running an app on java 8? That might fail at runtime
a
stately is for native ios side. I can try to check what build I use around. My binaries are well in java 8 (checked jar files this morning)
3 Views
Open in Slack
PreviousNext
Powered by