https://kotlinlang.org logo
#getting-started
Title
# getting-started
b

Bernhard

03/13/2024, 7:48 AM
is there a reason yet to switch to JVM 21? most of my company's projects have just gone up to 11 and 17 so adding another version to the mix without clear benefits would probably just be annoying
1
j

Jeff Avery

03/13/2024, 2:18 PM
Gradle support isn’t there yet for JVM 21, so 17 is still probably the best idea. I tried moving forward a couple of days ago, new projects wouldn’t build, and I quickly rolled back 😉
b

Bernhard

03/13/2024, 2:19 PM
good to know, thank you!
c

CLOVIS

03/13/2024, 2:34 PM
Gradle support isn’t there yet for JVM 21
That's wrong, JVM 21 is supported since Gradle 8.5 (current version is 8.6)
b

Bernhard

03/13/2024, 2:34 PM
probably talking about plugins
c

CLOVIS

03/13/2024, 2:35 PM
Better say which ones, then. I've been running on JVM 21 since 8.5 was released, never saw any issues with it.
b

Bernhard

03/13/2024, 2:36 PM
thanks for the input, I'll take a look
c

CLOVIS

03/13/2024, 2:37 PM
To answer your original question: there are a few performance improvements, but nothing major. There shouldn't be any breakage either, so basically it's a low-risk low-reward upgrade. If I were you, I'd still do it somewhat soon, just in case you're impacted by one of the security fixes, but I wouldn't make a big deal of it.
b

Bernhard

03/13/2024, 2:38 PM
those fixes get backported to 17 though, correct?
c

CLOVIS

03/13/2024, 2:38 PM
Depending on your JDK vendor, they may or may not be.
b

Bernhard

03/13/2024, 2:38 PM
we're on eclipse temurin
c

CLOVIS

03/13/2024, 2:39 PM
I couldn't tell you for sure as I didn't really look into it, but I have heard good things about them.
The new big thing is Project Loom (virtual threads), but if you're already using Coroutines, it won't do much for you. If you're not using coroutines, you may want to look into it, but it should mostly be transparent whenever the frameworks you use get an upgrade.
b

Bernhard

03/13/2024, 2:41 PM
exactly, that's the big thing I've read about; we're not using coroutines yet (spring web servlet) so that might be a nice boost
c

CLOVIS

03/13/2024, 2:46 PM
Do you manage threads/locking directly? If you don't, you may just upgrade Spring and the JVM. There may be some config to enable them somewhere in Spring, but that should be about everything you need to do. Benefits will be mostly about lower memory footprint for the same number of (virtual) threads, especially in IO-bound workflows (which is likely the case if you're doing the standard web-server-queries-database stuff).
b

Bernhard

03/13/2024, 2:46 PM
a couple of ThreadLocals but nothing else
👍 1
IIRC that one has transparent support for Loom
c

CLOVIS

03/13/2024, 2:48 PM
That's what I heard as well, but I don't use Loom, so I can't say for sure
I'm deeply in the coroutines world ahah
j

Jeff Avery

03/13/2024, 6:18 PM
@Bernhard My bad then! I could have sworn I was getting Gradle errors when creating default projects…. must have been plugins or something else.
r

Riccardo Lippolis

03/13/2024, 8:24 PM
ThreadLocals are bound to virtual threads indeed, so that works. Keep in mind that because of the fact that Virtual Threads are relatively short-lived compared to traditional threads (they should not be pooled), the ThreadLocals will also be more short-lived. Depending on the use case that might be exactly what you want. But some (mostly older) libraries/frameworks use ThreadLocals to cache objects that are expensive to create, so that might cause a performance degradation on Virtual Threads. (E.g. the Jackson JSON library did some work to improve the performance on virtual threads specifically for this issue, see: https://github.com/FasterXML/jackson-core/issues/919 )
b

Bernhard

03/13/2024, 8:26 PM
oh, thank you for pointing that out, yeah, I've seen it used both ways (state in a thread or used as a cache for http responses)
2 Views