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

61–70 of 191 posts

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

#61

Post by jayd16 »

twic wrote: post #50
PaulHoule wrote: post #36

(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 b…

I think the biggest impact of virtual threads is that the ecosystem will abandon asynchronous APIs. No more futures, callbacks, servers where you have to make sure not to block the thread, reactive frameworks, etc. Just nice simple imperative blocking code. Nima is the first example i've seen: https://helidon.io/nima We've had two production bugs in the last two weeks caused by handlers blocking the server thread in…

You'll still have the structured concurrency calls but that's much better than pure callback hell.

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

#62

Post by Quekid5 »

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.

I believe, e.g. ZIO 2.next is doing something like this, dynamically deciding whether running something async or just doing the blocking thing depending on the availability of VThreads... but of course that's Scala, so YMMV.

Without a way to trampoline computation (or transform code appropriately) it's probably impractical to do anything like that.

(And of course, still many caveats as the sibling post points out.)

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

#63

Post by grumpyprole »

unregistereddev wrote: post #3
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…

Pattern matching is a neat tool to keep in the toolbox. When it's the right tool for the job, it is really cool and is a lot cleaner than a bunch of conditional checks. However, I rarely reach for it. Maybe my use cases are unusual? I am genuinely curious how often other developers find pattern matching to be the best tool for the job.

One example for you: anytime you needed to use the "Visitor pattern" to do a transformation from one representation to another - you don't need it now. Sealed classes and pattern matching will be more succinct and easier to reason about.

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

#64

Post by papercrane »

yankput wrote: post #60
PaulHoule wrote: post #36

(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 b…

Virtual threads are strictly better than normal threads, no? I am thinking of any reason to still use traditional threads. Is there any downside?

Currently virtual threads aren't a good match if you have a CPU heavy workload. The scheduler isn't fair and if your code doesn't enter into any blocking code it won't be unmounted from the carrier thread.

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

#65

Post by logicchains »

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

Do you know if clojure will be adopting these virtual threads, or still using the macro-based approach?

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

#67

Post by krzyk »

brabel wrote: post #43
krzyk wrote: post #34

Earlier quoted context omitted.

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.

That's pretty disingenuous. Groovy has always run on newer JDK versions before they even get released. One year ago, Gpars already supported Virtual Threads: https://groovy.apache.org/blog/gpars-meets-virtual-threads As a heavy user of Groovy/Spock, though, I agree that upgrading Groovy itself can be challenging, unfortunately. Really depends though on how many edgy Groovy features you relied on :).

Not always for sure. We started JDK upgrades with 9 and went +1 every half year and Groovy was lacking with one of 10, 11, 12 or 13. It got so tiring that we had to let it go. Fortunately our tests were mostly JUnit 5, so it wasn't much of work.

We only used it for Spock AFAIR.

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

#68

Post by cogman10 »

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

It's somewhat unfortunate that structured concurrency ended up being a preview feature in 21. I agree that it's a great addition but man it'd be nice if it made the LTS.

As it stands, probably won't be heavily used until Java 25.

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

#70

Post by Svenskunganka »

Jtsummers wrote: post #25
mrkeen wrote: post #16

In the code example for virtual threads, I have no idea what will happen in parallel. How do I reason about the order in which the calls change the state of the world?

That's all sequential code, it would be run inside a single "virtual thread". Note that the async code on the right is also sequential, just structured through an async API.

From my perspective they're not entirely equivalent. The async variant seems to be batching getImages and saveImages, while the sync variant gets and saves each image individually, sequentially.
Post reply on HN