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

351–360 of 555 posts

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

#351

Post by kaba0 »

Rapzid wrote: post #205
avodonosov wrote: post #185

Earlier quoted context omitted.

In javascript the analogue is async / await, only without the need to manually mark code "async"

If you want to return a future you'll need to note that in the return type.

But that arguably doesn’t use this feature to its fullest — the most naive/easy to comprehend way to do concurrency is to start up multiple threads calculating something and simply wait for all of them to return, and at this point you are free to use the calculated results as is. This is the most-idiomatic way to make java virtual threads (with a try-with-resources block)

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

#352

Post by [deleted] »

nicktelford wrote: post #324
layer8 wrote: post #317

> However, due to the large number of virtual threads that can be created, developers should use thread-local variables with caution. What is the problem here? Just the per-virtual-thread memory consumption by the variable when it is used (which would be expected)?

Lock contention IIRC

[deleted]

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

#353

Post by the-alchemist »

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…

The "original billion dollar mistake" is lack of runtime bounds checking (in the creator's words), not the idea of a null/nil/undefined generally.

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

#354

Post by mattgreenrocks »

aardvark179 wrote: post #284
kjto wrote: post #73

> Virtual threads offer a more efficient alternative to platform threads, allowing developers to handle a large number of tasks with significantly lower overhead. they should have just called them "Tasks" leaving the already overloaded term "virtual" out of the conversation.

We went through a lot of iterations on what they should be called. They were originally called Fibers, but since they were extremely thread like it was decided they should be actual threads, so they should be some type of thread. Once that decision was made the question then becomes which adjective to add to Thread, and things like LightWeight, Small, etc. were ruled out as smaller or more lightweight threads might b…

Thanks for the explanation. That makes a lot of sense.

Naming things well is harder than making said things sometimes.

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

#355

Post by layer8 »

nicktelford wrote: post #324
layer8 wrote: post #317

> However, due to the large number of virtual threads that can be created, developers should use thread-local variables with caution. What is the problem here? Just the per-virtual-thread memory consumption by the variable when it is used (which would be expected)?

Lock contention IIRC

But the lock would only need to be per platform thread?

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

#356

Post by jayd16 »

kosolam wrote: post #304

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

If you want to run concurrent io requests, don't you still need to use an async framework and all the fork/join logic? I suppose the slow and naive way is now easier to let limp along as you won't run out of threads?

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

#357

Post by dkarl »

brabel wrote: post #207
kabes wrote: post #176

Earlier quoted context omitted.

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 fo…

> I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder. I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a conf…

Depending on what is in your cache, Maven will satisfy dependencies differently. You can go out of your way to nail down your dependencies (analogous to a Javascript lock file) but it goes against the grain of how Maven is designed. Maven encourages pretty sloppy dependency resolution by default, and that's what you'll see if you look inside the artifacts you depend on.

There may be other issues as well, because this was an issue that affected Maven throughout my years of using it, in contrast to SBT, which in my experience had this issue much less often (though it definitely did from time to time.)

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

#358

Post by tehbeard »

lenkite wrote: post #183
tehbeard wrote: post #97

Earlier quoted context omitted.

Java has the lingering shadow of Oracle hanging over it. That legalistic hydra is enough to make you second guess using it.

Would you ditch Linux, because Canonical has been making concerning decisions with Ubuntu ?

False equivalence.

Canonical doesn't own the Linux trademark, nor have the litigation history.

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

#359

Post by wolf550e »

bullen wrote: post #295

NIO solved the problems with threads on the network in Java 1.5 (seminal cornerstone API that also had the concurrency package and rewrote the entire JVM memory model), but only in 1.7 the epoll solution became stable. 2004 -> 2011, 7 years! Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. Many nuclear power plants wasted on the kernel.

> Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers.

How does this work around the kernel? This lets you write java code that uses async IO but make it look nice, like golang code. But this isn't DPDK.

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

#360

Post by throwaway2847 »

jayd16 wrote: post #356
kosolam wrote: post #304

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

If you want to run concurrent io requests, don't you still need to use an async framework and all the fork/join logic? I suppose the slow and naive way is now easier to let limp along as you won't run out of threads?

Why would you need an async framework? All blocking I/O in the Java runtime has been changed to yield in a virtual thread.
Post reply on HN