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

371–380 of 555 posts

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

#371

Post by kaba0 »

jayd16 wrote: post #367
throwaway2847 wrote: post #360

Earlier quoted context omitted.

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

They added the structured concurrency package because you still need some kind of async framework for concurrency. Maybe the confusion is just the term "framework" as opposed to API? I don't mean a third party library is needed. The built in JDK alone is sufficient but you're still juggling promises/futures and the like.

You don’t really need anything, they just make forking and subsequent joining+exception handling easier. You can just use the decades old thread api over virtual threads as is if you wish, but this “structured concurrency” concept, similar to goto vs structured control flow will make it much more productive and easier to reason about.

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

#372

Post by lightbendover »

vrnvu wrote: post #187
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…

Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... isn't too far removed from some of what I've seen in big tech, especially architecture-wise. Certainly less costly absurdity.

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

#373

Post by vasac »

jve wrote: post #311
papercrane wrote: post #270

Earlier quoted context omitted.

If you want to use the Oracle runtime you need to pay Oracle. But the code itself is open source and you can instead use the Azul, Amazon, Red Hat, BellSoft, etc.. runtimes.

Finally got to the answer. So it IS paid from one particular vendor. I understand there are free options. But that makes it a mine in a field if you are not knowledgable enough. It went this deep into threading to really get an ack that there is a big red O' mine in there. And there is one piece that wont run without big red O... :(

It's the same mine in a field as RHEL (a commercial Linux distribution). However, that has never prevented anyone from using other free distributions.

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

#375

Post by jpgvm »

haspok wrote: post #326
jpgvm wrote: post #278

Earlier quoted context omitted.

In my experience the zero to something stage lasts way longer than people think and the cost of using immature and badly suited stacks like Typescript/etc bites way sooner than people think. They just keep pushing through it and telling themselves this is faster and everyone else is doing it so it can't be wrong. Case and point I built a new service recently in Kotlin on JVM. It's a SQL translation gateway that maps…

Fun fact: JDBC was one of the (if not the most important) blocking APIs that people tried to convert or redesign / reimplement as async, and failed miserably. Now, with the advent of virtual threads this should no longer be a problem! JDBC can block all day long, and your app will still scale without a problem.

Yeah will be good to not need R2DBC or the Rx APIs etc.

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

#376

Post by kaba0 »

the-alchemist wrote: post #340
nicktelford wrote: post #324

Earlier quoted context omitted.

Lock contention IIRC

Yeah, poor performance and memory usage. In the Java world, thread locals are java.lang.ThreadLocal, basically a hashmap from thread to variable. Using a ThreadLocal is (usually) a code smell. It's optimized / supposed to be used with just a few threads, not millions.

For what it worth, there actually is a separate JEP (I believe this: https://openjdk.org/jeps/429 ) for a new, scope-bases solution that promises much better performance.

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

#377

Post by royjacobs »

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)?

Typically ThreadLocals are used whenever something is costly to initialize per-request. The rule of thumb is usually: you might want to use some heavy object without locking, so you stick into a ThreadLocal.

However, if suddenly you have a million threads then this optimization doesn't work anymore. Sure, the concept of ThreadLocal still works, but in practice you'll end up creating a million of these heavy objects - something you wanted to avoid!

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

#378

Post by kaba0 »

seti0Cha wrote: post #362
kaba0 wrote: post #195

Earlier quoted context omitted.

Gradle is a better build tool from a purely architectural point of view (though it is quite disliked, I believe mostly due to the ultra-complex android build system being built on top and giving it a bad name), but the Maven repo system is absolutely better than most contemporary repositories, proved by its comparably rare side-chain attacks.

I dislike it because of the ultra-complex build system that over-ambitious devops engineers ended up building in my shop. Our build system was the hardest part of our code base to reason about, which is pretty screwed up.

Well, that’s on them — were they developers in any language they could have also made a mess there. I have seen my fair share of random custom maven plugins as well, which have more bugs than features.

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

#379

Post by kosolam »

jayd16 wrote: post #367
throwaway2847 wrote: post #360

Earlier quoted context omitted.

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

They added the structured concurrency package because you still need some kind of async framework for concurrency. Maybe the confusion is just the term "framework" as opposed to API? I don't mean a third party library is needed. The built in JDK alone is sufficient but you're still juggling promises/futures and the like.

The complexity of an async lib/framework such as i.e. projectreactor stems from that your code stops being linear. And so is the dataflow. This is the core of the issue. You trade simplicity for performance. Using futures you can still write simple linear code. The problem is that thread based execution doesn’t scale well when the threads are mostly waiting for io, such as i.e. an http request. That is, it was a problem until virtual threads arrived.

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

#380

Post by seti0Cha »

tsss wrote: post #193
hintymad wrote: post #13

Earlier quoted context omitted.

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

The younger generation chose Go because they're dumb and fell for the Google marketing hype. Most of them have never even used Java outside of school.

The younger generations of coders are indeed more susceptible to hype, but if you go around dismissing things that are hyped, you're going to miss out on a lot of good things. I've got 15+ years of Java experience, and I think Go is a nice language and has some real strengths. From what I can see, the primary difference with Java isn't the build system or the binaries, it's the decision to strongly favor simplicity and readability over expressiveness. The payoff for this is that you can jump into any Go codebase and figure out what's going on fairly quickly. You don't need to pull down the source, fire up an IDE and start drawing object diagrams, you can figure out what it's doing by skimming the source on Github. I find this very useful.
Post reply on HN