https://kotlinlang.org
Join Slack
<Gradle 8.5-rc-1> was released today, which means you can finally have Gradle projects compiling you...
# feed
s
Gradle 8.5-rc-1 was released today, which means you can finally have Gradle projects compiling your Kotlin code to JVM21 bytecode! e.g. here is the build.gradle.kts of one of my demo projects using 
kotlin { jvmToolchain(21) }
. (Technically you could already configure Gradle 8.4 to produce JVM21 bytecode, but the Gradle script itself couldn't be executed on a JVM21, that has changed now.)
🎉 17
d
Anyone know of a resource that details the extent to which Kotlin does/does not take advantage of new JVM21 runtime features?
h
With the toolchain feature I absolutely don’t understand the need to run Gradle itself with 21.
☝️ 2
m
And with this you can even configure the ProGuard version so that you can also create release builds with Java 21.
👍 1
s
I feel it makes things easier to have just one Java version installed that runs Gradle and also builds the artifacts.
plus1 4
s
@Michael Paus the ProGuard version of what? I'm mostly working on Kotlin server apps, so I haven't got experience with android or Compose Multiplatform.
s
The ProGuard version for building the desktop version.
7.4.0 has support for JVM 21, where 7.2.2 (used by Compose 1.5.10 by default) fails.
plus1 1
h
Well, setting the Java toolchain is only 1 line and it sets the target explicitly, so your are in control of the JVM target. Otherwise you can easily use the default Java version provided by the CI and it will accidentally use a different version after a CI change breaking your consumers, see Exposed for a real world example…
s
That's why I explicitly set the same Java version in CI I have installed locally. 🙂
Copy code
- name: Set up Java JDK 18
  uses: actions/setup-java@v3
  with:
    distribution: 'temurin'
    java-version: '18.0.2+9'
m
I just fought with that yesterday because up to now I needed two Java versions to load and configure in my GitHub action. What could be simpler than using just one version instead of two?
➕ 1
h
They just have different meanings. For example AGP requires to run Gradle with Java 17, while it uses Java 8 as JVM target for Android apps.
s
Yes, Android is special.
m
Even for Android I use Java 17. You just have to be careful which features you use. Why do you think that Android still needs Java 8?
h
Which Android device does support Java 17?
s
I was thinking that for Android I can either choose Java 8 or Java 11.
Oh, just looked it up. Android 14 supports Java 17
Android 13 was still Java 11
I guess we will see Java 21 support in Android 20 😄
m
The desugaring does the trick even on older devices. I just test my app on an old Samsung Galaxy Tab 4.
s
Since I write my Android apps in Kotlin I seldom miss API for anything. 🙂
m
Yes, but I can also use many java libraries that way which now require Java 11+. Bye, bye Java 8 😉.
🎉 1
s
By now I replaced everything with Kotlin libraries. I only did not have a Kotlin replacement for Apache Commons Imaging and Adobe XMP Core - so I ported them myself. No Java libs anymore for me. 💪
m
My current app is primarily a desktop application and I keep the Android version more or less for fun because I do not really need it. In the beginning I even had an iOS version but getting rid of all that Java was just too much work.
s
What library do you need that has no Kotlin equivalent?
I told my manager that there is nothing like Apache Commons Imaging for Kotlin Multipatform and he allowed me to port that project & contribute it back as https://github.com/Ashampoo/kim ❤️ Porting a Java library to Kotlin and solving all the challenges it brings was quite fun. I would do it again if there is a benefit for my company / the app I’m working on.
K 1
m
My own legacy libraries, JTS, JSoup, Apache PDFBox and POI next.
s
Okay, I know that POI is a monster. That’s a huge task. 👀
PDFBox should be doable.
Not familiar with the others.
m
Would Ashampoo be a replacement for com.drewnoakes:metadata-extractor?
s
Yes.
👍 1
Eventually at least. Metadata-extractor has more formats right now, but I’m working on it.
Actually I would have preferred to port metadata-extractor to Kotlin due to its cleaner code and wider support, but unfortunately it lacks write support I require for Ashampoo Photos.
Write support is not easy to implement in metadata-extractor due to the way it reads the files… it skips over a lot of data and just picks what it needs. This way you can’t restructure a new file for writing. Commons Imaging reads in a way it can manipulate the data - and so does Ashampoo Kim.
I assume that metadata-extractor will never see write support, because it would require a major redesign for that and to me it looks like that this library is in maintenance mode.
PDFBox could become a challenge regarding the encryption stuff. 👀 JSoup looks also doable. It’s around the size of porting Adobe XMP Core - which I also did in https://github.com/Ashampoo/xmpcore
XmlUtils was a great help.
m
Here is also some background information on the Android/Java compatibility. I deliberately have chosen this older article to show how long Android already supports more than just Java 8. https://www.mobileit.cz/Blog/Pages/android-java-release-train.aspx
👍 1
s
I think if someone has some free time and wants to contribute to the ecosystem working on a port of one of these libraries would be a great help. 🙂
m
Yes, but who has all this free time 😢.
s
Students or people looking for a job maybe. Having a nice GitHub repo helps in finding good jobs. At least my GitHub repo looked good to the relevant people. 😄
„Yes, I can write Android apps. Look over here.“ 😉
But I’m indeed thankful that I got paid for working on Ashampoo Kim 🙏🏻 👀 That would have been a lot of weekends otherwise. I believe it took me 4 to 6 weeks. I got interrupted with other things, so I’m not 100% certain.
But sometimes people like @pdvrieze somehow find time for great contributions to the ecosystem and this makes me happy. 😊 https://github.com/pdvrieze/xmlutil
Actually I’m really excited to see the whole ecosystem grow. That’s why I’m paying close attention to #feed . Many libraries presented here are of good use for me. The next version of Ashampoo Photos will use https://github.com/Wavesonics/compose-multiplatform-file-picker, which was announced here. ❤️
➕ 1
And I’m really glad that my company lets me contribute to the ecosystem, too. I consider this as one of the benefits working at Ashampoo. 😄
12 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by