is there a reason yet to switch to JVM 21? most o...

# getting-started

[Bernhard]

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

[Jeff Avery]

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 😉

[Bernhard]

good to know, thank you!

[CLOVIS]

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)

[Bernhard]

probably talking about plugins

[CLOVIS]

Better say which ones, then. I've been running on JVM 21 since 8.5 was released, never saw any issues with it.

[Bernhard]

thanks for the input, I'll take a look

[CLOVIS]

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.

[Bernhard]

those fixes get backported to 17 though, correct?

[CLOVIS]

Depending on your JDK vendor, they may or may not be.

[Bernhard]

we're on eclipse temurin

[CLOVIS]

I couldn't tell you for sure as I didn't really look into it, but I have heard good things about them.

[CLOVIS]

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.

[Bernhard]

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

[CLOVIS]

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).

[Bernhard]

a couple of ThreadLocals but nothing else

[Bernhard]

IIRC that one has transparent support for Loom

[CLOVIS]

That's what I heard as well, but I don't use Loom, so I can't say for sure

[CLOVIS]

I'm deeply in the coroutines world ahah

[Jeff Avery]

@Bernhard My bad then! I could have sworn I was getting Gradle errors when creating default projects…. must have been plugins or something else.

[Riccardo Lippolis]

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 )

[Bernhard]

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)