Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 21: The Nice, the Meh, and the Momentous

horstmann.com

Post reply on HN
Print view View original

31–40 of 191 posts

Re: Java 21: The Nice, the Meh, and the Momentous

#31

Post by rusk »

frou_dh wrote: post #4
ecshafer wrote: post #2

Java getting better pattern matching is a great change. Id really like more of the functional features to make it into Java. I would love if Java pattern matching could at least get to the level of ruby pattern matching. Ruby pattern matching will allow you to deconstruct arrays and hashes to get pretty complicated patterns, which is really powerful. Right now it seems like Java might have that with a lambda in the p…

I really like that Ruby throws NoMatchingPatternError if none of the patterns match. It's a bit like the much-acclaimed exhaustive pattern matching in static languages (though at runtime rather than compile-time, obviously) and better than just silently falling off the end, which IIRC is what Python's pattern matching does.

In Python you can terminate a for loop with else, which will be run whenever the loop runs to the end without breaking

Re: Java 21: The Nice, the Meh, and the Momentous

#32

Post by Someone1234 »

munk-a wrote: post #22
Someone1234 wrote: post #17

If you're viewing that website on a desktop, I strongly suggest removing max-width: 90ch from the body css. Instead of 50% white space, it goes full width and makes the table substantially more readable (particularly the code samples).

Hilariously enough I was initially confused by this comment because the webpage rendered so readably for me - the base CSS is actually quite reasonable and because I have JS disabled by default the page never re-rendered into the thinner mode.

It may be my specific setup. But on a 1440p display, 125% OS scale, I'm seeing more white left/right than actual content in the middle. It is also wrapping the code making it difficult to read.

Completely readable at 100% width though.

Re: Java 21: The Nice, the Meh, and the Momentous

#33

Post by defatigable »

larperdoodle wrote: post #21
adra wrote: post #7

Virtual threads are going to be great, but they're still limited (still starved the pool when used with 'synchronized' blocks), and they aren't the structured concurrency power houses like kotlin coroutines, but its an invaluable tool that will only continue to accelerate as the ecosystem moves to adopt them. Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone.…

Why haven't places updated already? It's not that much work to update. Where I work we always go to the new LTS version as soon as it's supported by gradle. Doesn't cross anyone's mind to _not_ upgrade.

This is a niche case, but I spent months trying to upgrade one of our services from one LTS version to the next (I forget which). We encountered a weird bug where services running on the latest JRE would mysteriously corrupt fields when deserializing thrift messages, but only after running for a little while.

After an enormously unpleasant debugging cycle, we realized that the JIT compiler was incorrectly eliminating a call to System::arrayCopy, which meant that some fields were left uninitialized. But only when JIT compiled, non-optimized code ran fine.

This left us with three possible upgrade paths:

* Upgrade thrift to a newer version and hope that JIT compilation works well on it. But this is a nightmare since A) thrift is no longer supported, and B) new versions of thrift are not backwards compatible so you have to bump a lot of dependent libraries and update code for a bunch of API changes (in a LARGE number of services in our monorepo...). With no guarantee that the new version would fix the problem.

* File a bug report and wait for a minor version fix to address the issue.

* Skip this LTS release and hope the JIT bug is fixed in the next one.

* Disable JIT compilation for the offending functions and hope the performance hit is negligible.

I ultimately left the company before the fix was made, but I think we were leaning towards the last option (hopefully filing a bug report, too...).

There's no way this is the normal reason companies don't bump JRE versions as soon as they come out, but it's happened at least once. :-)

In general there's probably some decent (if misguided) bias towards "things are working fine on the current version, why risk some unexpected issues if we upgrade?"

Re: Java 21: The Nice, the Meh, and the Momentous

#34

Post by krzyk »

Brystephor wrote: post #26
larperdoodle wrote: post #21

Earlier quoted context omitted.

Why haven't places updated already? It's not that much work to update. Where I work we always go to the new LTS version as soon as it's supported by gradle. Doesn't cross anyone's mind to _not_ upgrade.

1) dependencies need to be upgraded. for example, not all versions of Gradle support all Java versions. So you need to upgrade Gradle to upgrade Java. 2) other things are deemed to have higher priority. 3) people are satisfied with existing features and don't want to spend energy to upgrade to something that doesn't provide immediate value. 4) folks aren't educated on what the benefit of switching would be so why wou…

Gradle/groovy is a liability for any jdk upgrades (similarly like lombok, but it usually supports new JDK at release, not before).

We ditched spock because of groovy, and never looked back. Now at jdk 21, previously at 20.

Re: Java 21: The Nice, the Meh, and the Momentous

#35

Post by skwirl »

adra wrote: post #7

Virtual threads are going to be great, but they're still limited (still starved the pool when used with 'synchronized' blocks), and they aren't the structured concurrency power houses like kotlin coroutines, but its an invaluable tool that will only continue to accelerate as the ecosystem moves to adopt them. Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone.…

Do you have to baseline on Java 21 if you want to add support for virtual threads? Couldn't you continue using heavyweight threads on older versions of Java? My understanding is that both use the same Thread abstraction.

Re: Java 21: The Nice, the Meh, and the Momentous

#36

Post by PaulHoule »

(1) It's a bit of a bad smell (which he points out) that records aren't being used much at all in the Java stdlib, I wrote something that built out stubs for the 17 and 18 stdlibs and that stood out like a sore thumb. I do like using records though.

(2) I've looked at other ways to extend the collections API and related things, see

https://github.com/paulhoule/pidove

and I think the sequenced collections could have been done better.

(3) Virtual Threads are kinda cool but overrated. Real Threads in Java are already one of the wonders of the web and perform really well for most applications. The cases where Virtual Threads are really a win will be unusual but probably important for somebody. It's a good thing it sticks to the threads API as well as it did because I know in the next five years I'm going to find some case where somebody used Virtual Threads because they thought it was cool and I'll have to switch to Real Threads but won't have a hard time doing so.

Re: Java 21: The Nice, the Meh, and the Momentous

#37

Post by yCombLinks »

larperdoodle wrote: post #21
adra wrote: post #7

Virtual threads are going to be great, but they're still limited (still starved the pool when used with 'synchronized' blocks), and they aren't the structured concurrency power houses like kotlin coroutines, but its an invaluable tool that will only continue to accelerate as the ecosystem moves to adopt them. Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone.…

Why haven't places updated already? It's not that much work to update. Where I work we always go to the new LTS version as soon as it's supported by gradle. Doesn't cross anyone's mind to _not_ upgrade.

The services I work on pump the entire business revenue from start to finish. A few nice to haves for devs aren't any where close in the risk calculation if something breaks

Re: Java 21: The Nice, the Meh, and the Momentous

#38

Post by pron »

tantamounta wrote: post #19
adra wrote: post #7

Virtual threads are going to be great, but they're still limited (still starved the pool when used with 'synchronized' blocks), and they aren't the structured concurrency power houses like kotlin coroutines, but its an invaluable tool that will only continue to accelerate as the ecosystem moves to adopt them. Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone.…

With the API being nearly the same, I keep just thinking that Virtual Threads are basically identical to Platform Threads except that they use far less memory (so you can have lots more of them). Are there any other actual differences? Better Peformance?

The relationship between throughput, latency, and concurrency in servers is expressed via Little's theorem. If your server is written in the thread-per-request style -- the only style for which the platform offers built-in language, VM, and tooling support -- then the most important factor affecting maximum throughput is the number of threads you can have (until, of course, the hardware is fully utilised). Being able to support many threads is the most effective improvement to server throughput you can offer.

See: Why User-Mode Threads Are Good for Performance https://youtu.be/07V08SB1l8c

Re: Java 21: The Nice, the Meh, and the Momentous

#39

Post by adra »

skwirl wrote: post #35
adra wrote: post #7

Virtual threads are going to be great, but they're still limited (still starved the pool when used with 'synchronized' blocks), and they aren't the structured concurrency power houses like kotlin coroutines, but its an invaluable tool that will only continue to accelerate as the ecosystem moves to adopt them. Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone.…

Do you have to baseline on Java 21 if you want to add support for virtual threads? Couldn't you continue using heavyweight threads on older versions of Java? My understanding is that both use the same Thread abstraction.

From an API perpective, you can always use reflection to cheat past the option to create virtual threads in pre-21 (without previews) java bytecode, but you need to do more to your code than just flip the switch to support virtual threads.

A virtual thread thread pool by definition is unbound. If you're binding data to a thread (eg. Thread locals, you now have a seemingly unbound list of threads that is now effectively a memory leak). I bumped into that one a few months ago with Netty that has a per thread cache for some things (thankfully you can turn off that cache). It was creating a significantly large waste of RAM that slowed down the application alone.

The other big one is as I mentioned the synchronized limitation. If you assume naively that anything can run in a virtual thread without worries, you're opening yourself up to deadlocks or at least significantly low performance code if you're relying on libraries/code that are synchronized using java monitors.

There may be more examples of gotchas, but these two are the most notable examples I have right now.

Re: Java 21: The Nice, the Meh, and the Momentous

#40

Post by [deleted] »

pron wrote: post #20
adra wrote: post #7

Virtual threads are going to be great, but they're still limited (still starved the pool when used with 'synchronized' blocks), and they aren't the structured concurrency power houses like kotlin coroutines, but its an invaluable tool that will only continue to accelerate as the ecosystem moves to adopt them. Expect a lot of libraries to start release versions that are java 21 baseline because of this feature alone.…

Structured concurrency in JDK 21 is not only a powerful and flexible library feature, but one that is built deep into the runtime in a way that allows observability into the relationships among threads: https://openjdk.org/jeps/453

[deleted]
Post reply on HN