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

361–370 of 555 posts

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

#361

Post by hderms »

nicktelford wrote: post #325
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. Can you expand on this a little? Are you referring to the necessity to copy between kernel memory and user-space memory, or something else?

Maybe io_uring?

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

#362

Post by seti0Cha »

kaba0 wrote: post #195
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…

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.

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

#363

Post by kaba0 »

marginalia_nu wrote: post #344
kaba0 wrote: post #327

Earlier quoted context omitted.

Are you writing everything with a so-called superoptimizer (because mind you, not even your hand-written assembly will be the fastest, hell, C++/Rust will likely beat it in the general case)? Because it has always been a tradeoff between programmer’s sanity-correctness-maintainability-productivity-performance, at the least. Java does very well on most of it, including performance — it will JIT compile code comparable…

Well I regularly do juggle millions of objects in Java. I'd estimate most Java application code is probably running at about a fifth the speed it could be. Modern computers are incredibly fast, but most of that speed is wasted copying data between representations and garbage collecting Stream API debris and boxed integers. Moreover, most Java applications using a database for storage do so in a dumb way that doesn't…

Well, as I mentioned there are escape hatches, but those come at a price in usually maintainability, e.g. using SoA, or external heap.

If you do have a million objects and it is indeed a performance bottleneck (as shown by the profiler) then it might be worthwhile to pursue these solutions, or even implementing them in another language. Noone claims that Java is for everything, but it is for most things.

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

#364

Post by sesteel »

jeroenhd wrote: post #43
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.

I think Java is an ugly language riddled with roundabout ways of implementing modern features, but I can't fathom why anyone would pick Go over Java. It's slightly worse in almost every way other than writing shell scripts or massively parallel workloads from scratch. In my experience, Java's problem is the same as C++'s when Java began to take over: you usually encounter it in projects stuck at ancient runtime versi…

It is about iteration and interpretation for me. For Java, there is more to consider, there is more to build, there is more to run, and there is more to move around. With Go, things tend to be faster and smaller. It is not feature soup... yet.

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

#365

Post by kaba0 »

haspok wrote: post #337
tm-guimaraes wrote: post #211

Earlier quoted context omitted.

Depends if they are talking about Spring the framework, or Spring Boot, the "conventions bootstrapper" Both of them do not have bad docs, maybe some sub project might have, but compared to RoR (sorry never used Django), Spring's projects docs are magnificent. Their problem could be navigation for someone new to it, or in the case of Spring Framework, just too much concepts. So, Spring Framework is basically "make eve…

> Both are full of reflection. That's how it keeps being very generic at its core. Reflection is not a feature, but a kludge - to conceal how non-expressive the core language is. Add annotations to that, and you might start asking yourself, what value does exactly Java's static type system add here, compared to a dynamic language (say Javascript)? Most of your errors will remain undiscovered until runtime, so why bot…

Unless your language is Coq or Idris, its type system will still be way way less expressive than what reflection can do — java’s type system is quite good, it only misses HKTs, and even where static types are insufficient, it has proper runtime types and error handling, so runtime exploration of dynamic data in a safe way is absolutely possible.

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

#367

Post by jayd16 »

throwaway2847 wrote: post #360
jayd16 wrote: post #356

Earlier quoted context omitted.

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.

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.

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

#368

Post by treis »

jeroenhd wrote: post #43
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.

I think Java is an ugly language riddled with roundabout ways of implementing modern features, but I can't fathom why anyone would pick Go over Java. It's slightly worse in almost every way other than writing shell scripts or massively parallel workloads from scratch. In my experience, Java's problem is the same as C++'s when Java began to take over: you usually encounter it in projects stuck at ancient runtime versi…

Instant compilation, single binary deploys, integrated linter, extensive standard library, and less magical performance. It's way fewer decisions and way less ceremony before you start writing actual code.

And, IMHO, duck typed systems are better than the Java style OOP.

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

#369

Post by kaba0 »

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... :(

Since OracleJDK is also just OpenJDK with a logo, I don’t believe that there is any software that runs on any recent OracleJDK but not on OpenJDK.

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

#370

Post by lightbendover »

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 billion dollar mistake

Eh, a billion dollars isn't too bad.

Post reply on HN