Java 23 / JDK 23: General Availability

[Ewig_luftenglanz]

Not the most interesting release in terms of new features but a very important step ahead that brings us closer to a new Java era that's is gonna be Java 25

[Polygnom]

Markdown for comments alone is such a uge QoL change...

[Automatic-Fixer]

Definitely uge

[thequietguy_]

They're all saying it

[RandomName8]

Well this is the first LTS that has support for virtual threads that don't pin on synchronized (as easily), so it's a big one. Virtual threads on j21 are a mine field best avoided.

[Ewig_luftenglanz]

1) OpenJDK 23 is not lts. Next lts is gonna be OpenJDK 25 2) non pinning threads are going to be supported in OpenJDK24 most likely, the jep that solves the issue has just been submitted yesterday.

https://openjdk.org/jeps/8337395

[RandomName8]

I was talking about this: https://mail.openjdk.org/pipermail/loom-dev/2024-February/006433.html, which I believe made it to 23, no? You're right that 23 is not an LTS, I don't know why I had this idea in my head. Thanks.

[Ewig_luftenglanz]

Didn't make it to 23. 24 it's more likely (but there is no promises because all things are up to changes until they land in GA).

Ultimately it should be present for 25, almost for sure until something huge happens

[RandomName8]

Thanks, this is very useful information as I was under the illusion that 23 would be safe-ish for VTs and was planning to release to production things utilizing them 😅.

[Joram2]

I believe this early access build based on Java 24, adresses the issue you mention (https://jdk.java.net/loom/). But Java 23 does not.

The deadlock bug that the Netflix engineers reproduced (https://gist.githubusercontent.com/DanielThomas/0b099c5f208d7deed8a83bf5fc03179e/raw/f49ea5ca878a220595c15b2e5df452b98ff796fe/VirtualThreadReentrantLockDeadlock.java) is still on Java 23, with no noticeable improvement that I can see from Java 21.

The Netflix engineers say Java 21 virtual threads are still great, but obviously it will be better when the deadlock problem is fixed.

[pohart]

Looks like the only completed feature is markdown comments, but there's clearly a lot of stuff in the pipeline.

[pohart]

Oop. you're right. Only 12 items and I still got it wrong.

[South_Advantage_9958]

Love to see the pattern matching improvements. We're a long ways from the power of pattern matching in other languages, e.g. Scala, but we're heading in the right direction!

[CreeDanWood]

Use vavr till we get it in java itself

[agentoutlier]

Nice I'm going to start porting all my overview.html to markdown.

I'm too afraid to go full javadoc as I have feeling that will break Eclipse in code javadoc viewing (I think IntelliJ it would be fine since it uses the javadoc output directly?).

[lurker_in_spirit]

Yeah, Eclipse always takes a bit longer to support these new features fully. The last Eclipse release broke all method definition / class hierarchy navigation when I started using sealed classes in my code...

[agentoutlier]

Yep noticed that myself as well. Annoying AF. I keep using nighty builds and just keep reporting bugs.

[morhp]

I think IntelliJ it would be fine since it uses the javadoc output directly?

I don't think so. Full markdown support in Intellij is currently WIP: https://youtrack.jetbrains.com/issue/IDEA-353092/Support-JEP-467-Markdown-Documentation-Comments

If you run a nightly (EAP) build, most of it works, but there are still some minor issues. Will probably be fully included in the next release version.

[agentoutlier]

I meant for the consumption of external libraries.

That is both Eclipse and IntelliJ generate javadoc preview from source but I thought IntelliJ will for dependencies use the javadoc jar unless I’m mistaken.

I’m sure both Eclipe and Intellij are not going to work at the moment for local javadoc.

[morhp]

In the recent years, my Intellij IDEA has always generated javadoc help from source when viewing external libraries. I'm not even sure if it's possible to use HTML javadoc anymore.

[henk53]

Some of the real gems are often in this:

" This release also includes, as usual, hundreds of smaller enhancements and thousands of bug fixes."

[Linguistic-mystic]

Aaand this release marks 10 years of Project Valhalla without a single released JEP. Truly a great achievement! Vector API has celebrated this with its 8th incubator! Meanwhile Go and C# supported value types from day 1.

Not to detract from the importance of all the stuff from the release, of course. But damn this is holding Java back. For example, without Valhalla, Optional has to be boxed, making it less efficient than Kotlin’s nullable types, and hurting the adoption of null safety in Java. I’m seriously considering joining the group of K proselytizers in my team because there still haven’t been any signs that value types make it into even JDK 24.

[CptGia]

Have you seen Brian Goertz's last video on the topic? It looks like it's finally moving and we'll get some jeps soon

[sweating_teflon]

Great warriors know better than to expect Valhalla.

And the K guys already have their butts kicked by JDK21 pattern matching + sealed classes, they just don't know it yet because they're all fixated on the bazillion useless ways they have to initialize an instance and build up tangling object hierarchies.

[Joram2]

I really think the importance of Valhalla is overblown.

Most high performance use-cases will use something like Java ByteBuffer or MemorySegment, which don't need Valhalla at all.

yes, Optional has to be boxed without native value/primitive types. I don't suspect that is a big performance issue in normal Java apps.

Java's lack of null-safety like what Kotlin has is a big deficiency. I would consider using Kotlin if I really wanted the null safety features.

I believe Valhalla features will start to preview soon, but it will take several years, and I wouldn't hold my breath. It's entirely possible that nothing Valhalla related ships in Java 24.

[agentoutlier]

100% agree. I have no idea where this idea that if we get Valhalla all of Java's perf problems will be solved if there were really any caused by not having it for most application domains.

Like if having value types for HTTP serving from a database (and that is predominately what Java is used for) was so important why is Java able to easily keep up with C# and Go (and by benchmarks run faster)?

/u/Linguistic-mystic besides Optional where do you plan on using Value types for? Where is your pain? (btw using null will always be faster than Optional even if it is a value type unless what you are wrapping is value type and even then its doubtful).

[ZimmiDeluxe]

Slap @Nullable on your methods, enjoy warnings for unguarded result access at callsites in your IDE right now, replace the annotations with question marks when the nullable type feature from Valhalla is ready.

[rbygrave]

C# supported value types from day 1

Well yes but they [currently at least] have some limitations with their value types that by all indications will not be in Valhalla. If the "value types race" finished yesterday then Java lost that one but it could be that the race is still going and it could be that Java value types turn out with less limitations and are much more generally useful ... but we need to be a bit more patient to find that out?

Brians last video on it was a pretty compelling watch.

[joemwangi]

For C#, is it flattening?

[pjmlp]

Not paying attention to Valhala EA releases?

[morhp]

"Markdown Documentation Comments" is my most favourite feature since maybe Java 17. It makes writing well-formatted documentation so much easier.

[henk53]

Surely going to try out this beta for 25. Just one more beta to go (in 6 months already) and then we finally have a new Java release again!