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

Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

infoq.com

Post reply on HN
Print view View original

171–180 of 555 posts

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#171

Post by seanparsons »

marginalia_nu wrote: post #18
seanparsons wrote: post #12

Well it's not really ushering it in, given that this is what Haskell has had for a decade at least.

Well, yeah. Haskell is a research language, while Java's stated design philosophy from day one has been to be conservative with adding new features, and judiciously add new features after they've proven useful in other languages.

So how does that make a difference to my point? The title is literally false as multiple other languages have already done it, Haskell in fact has even rewritten the underpinnings at least once the feature has been there so long.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#172

Post by flippinburgers »

surfsvammel wrote: post #74

Every time something show up about anything related to Java, the discussions turn to this flame war about what language are better or worse than Java. Why can’t we just discuss the article at hand? In this case, I’d love to hear more from experienced Java developers, with existing code-bases, who have tested these new virtual threads out.

The top level comment is someone gushing over Java so perhaps Java advocates bring this on themselves?

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#173

Post by kasperni »

piokoch wrote: post #70

While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: ht…

> Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production.

A typical request easily creates 100's of objects that needs to be garbage collected. Adding a single thread object on top of that means absolutely nothing. And how much garbage to you think reactive frameworks create? I can you tell you it is a lot more.

> Before getting too excited I advise to watch Tomasz Nurkiewicz lecture on the subjec

Don't waste your time. He is pretty clueless. I remember him complaining about lack of backpressure and composability. But this comes pretty much out of the box with loom.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#174

Post by 0xAFFFF »

nickstinemates wrote: post #169
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

`com.lol.myapp.factory.UserFactoryImpl.java` would like to have a word about its clear superiority

I you really want to stick to terrible naming and overused architectural principles in 2023 that's your choice but that's hardly a Java issue.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#175

Post by pjmlp »

spion wrote: post #165
pjmlp wrote: post #157

Earlier quoted context omitted.

Several commercial JDK options have offered compiling to single binary for 20 years, even if out of reach for common folks. GraalVM and OpenJ9 now make it available as free beer as well. https://docs.oracle.com/en/java/javase/20/docs/api/java.base...

Is that the modern Java equivalent of the single-method interface in Go? I can see its an abstract class - what do you do if you want to implement both Reader and Writer?

You implement both, duh.

Single method interfaces are what lambdas are for.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#176

Post by kabes »

TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

As a language java's not that bad at this point. But it still has cultural issues.

Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder.

Furthermore, since the language evolved so much in recent years, it's hard for newcomers to know what the best practices are. There's at least 6 different ways to iterate over map values. Which one should I pick?

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#177

Post by pjmlp »

jsiepkes wrote: post #160
pjmlp wrote: post #157

Earlier quoted context omitted.

Several commercial JDK options have offered compiling to single binary for 20 years, even if out of reach for common folks. GraalVM and OpenJ9 now make it available as free beer as well. https://docs.oracle.com/en/java/javase/20/docs/api/java.base...

We used ExcelsiorJET to create (pre-compiled) executables for Java (Swing) applications back in 2009 if memory serves me right.

Yes, unfortunely they went out of business, leaving PTC and Aicas as survivors from those days.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#178

Post by karussell »

piokoch wrote: post #70

While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: ht…

Based on that I found this reddit discussion where Ron Pressler (Loom project) commented:

"The posts read like they’re leading to a negative conclusion, but at the end of part 2 it turns out that the current Loom prototype does perform as well as async in their experiments ..."

https://www.reddit.com/r/java/comments/kmn6m3/do_looms_claim...

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#179

Post by spion »

pjmlp wrote: post #175
spion wrote: post #165

Earlier quoted context omitted.

Is that the modern Java equivalent of the single-method interface in Go? I can see its an abstract class - what do you do if you want to implement both Reader and Writer?

You implement both, duh. Single method interfaces are what lambdas are for.

Its not an interface though:

  public abstract class Reader
Did Java add multiple inheritance or am I missing something?

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#180

Post by 0xAFFFF »

wiseowise wrote: post #167
surfsvammel wrote: post #64

Earlier quoted context omitted.

It’s not hard to find people who want to write Java. I do it all the time. We have been hiring and writing Java code for fifteen years and have not seen a decline in the interest.

It’s hard to find quality people who want to write Java.

Where I am it's hard to find quality people period. If anything targeting Kotlin or Scala developers usually yields slightly better developers but also further restricts an already small candidate pool.
Post reply on HN