Java 23 - Better Language, Better APIs, Better Runtime

_Java 21 was an explosive release, but 22 and 23 are no slouches either:_
_• from unnamed patterns to the string template removal_
_• from primitive patterns to module imports_
_• from Markdown in JavaDoc to the FFM API_
_There are plenty of improvements to the language, API, and VM to discuss - whether new, improved, or finalized. So let's go over them!_

Tags: #Java #FOSS #opensource #community

Thank you so much for the content. I would like to see string templates come back in the future!

[Traversed-gh]

implicit import module java.base with JEP 477 is going to be amazing for experimentation

[VisruthCV]

Great presentation🎉🎉🎉 Thanks for publishing.

[prdoyle]

FWIW the Generational Hypothesis does not need to be true in order for generational GC to be useful. Modern (like from the last 15 years) nurseries make very short-lived objects perform on par with stack allocation, making high-quality time-consuming escape analysis much less important.

[shadeblackwolf]

tri-state booleans with null can be very sensible. for example to represent a cached value. "Is this fact about my user true?" yes (cached from recent request), no (cached from recent request), or the cache returns a null to tell you to go get it from the slower access primary source

[ebuzertahakanat]

I'm more curious about the runtime optimizations side of things will there be video on that?

[sblantipodi]

Before thinking about better things I think it's important to fix what's currently broken. AWT and Swing uses 25 years old APIs and most of the features are now broken on modern OSes.

[Shelton_fr]

Is my team the only one in the world using jdk 22 in production?😂

[Jakob-mfus]

Just saying, removing Unsafe without real replacements is not the way to go, I think giving Users access to native methods for things like theUnsafe (jdk internal Unsafe), with things like an unsafe scope like in Rust, would be way better. Since every API exposed in the newest Version of Java is Type Safe with many checks etc. will mean an reduction in features and performance, thus we will see libraries pushing bytecode at and before runtime, what I think is much more dangerous, than giving access to all of these native methods and also makes it much harder to debug, when something goes south.

Kind regards,
Jakob

[renbangbprd]

Bring the low memory usage, I hope lilliput+leyden+valhalla can reduce java memory usage by ~50%

[shadeblackwolf]

One problem of try with resources, is that it does not cover the usecase where you're preparing resources to be used at a different place and time in the code. An example would be preloading the End of level cutscene in a videogame while a player is playing a level, then executing it based on the player reaching the end of level trigger, to avoid unneeded load screens.

[mchiareli]

I am here stuck with Kotlin, a language full of bs

[rtorello]

There's kind of a "real problem" in that providing feed-back to these people is virtually impossible. I'm 49 years old, and started programming Java when it came out in 1997 at M.I.T. I did leave it, but I've been doing it everyday for a decade now, but I don't know who to contact (or how) to have a conversation about it.

[jNayden]

implicit import of java.base is absurd... makes new people to learn Java even harder.. why sometimes you need it and sometimes you dont.... no one cares about demos guys.. java is not for demos... please remove this meaningless features that add complexity.

[krellin]

Averages are nonsense, Gil covered that extensively for years now. Stop using average pause time especially in context of GC of all things... average will completely hide a massive highest pause time.

ZGC is actually awesome though.

[krellin]

basically only actually useful thing for me was better switch statements
still 0 reason to go back to java from kotlin

FFM is nice too but needs testing to see if they are actually doing it faster...