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

101–110 of 191 posts

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

#101

Post by pron »

riku_iki wrote: post #87
zmmmmm wrote: post #76

Earlier quoted context omitted.

I think virtual threads are huge. The problem with regular threads is (a) multi-kb memory stack per thread and (b) consuming a file handle. Either of those severely limits the scalability of the most "natural" parallelism constructs in Java (perhaps generally). Whole classes of application can now just be built "naturally" where previously there were whole libraries to support it (actors, rxJava, etc etc). It make ta…

> Either of those severely limits the scalability you can avoid both issues by using 20yo executorservice.

If the code is simple, blocking code, then the number of threads required in the pool is the average total duration of a request times the fanout times the request rate. That number can easily reach many thousands and more.

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

#102

Post by riku_iki »

pron wrote: post #101
riku_iki wrote: post #87

Earlier quoted context omitted.

> Either of those severely limits the scalability you can avoid both issues by using 20yo executorservice.

If the code is simple, blocking code, then the number of threads required in the pool is the average total duration of a request times the fanout times the request rate. That number can easily reach many thousands and more.

yes, you shouldn't add blocking code into executorservice..

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

#103

Post by rr808 »

hinkley wrote: post #58

What's the Scala community think about this development? I would think this would affect them quite a lot. Google is not helping.

Scala community always thinks they're the best tool. The size of the community is at best static though, Kotlin and re-energized Java took away most of the reasons for using it. I know in my company the teams that went the Scala route complain of huge compile times and really struggle to find people, I think we'll probably port back to Java.

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

#104

Post by rr808 »

waynesonfire wrote: post #18

> Over 10,000 bug fixes Most of which were likely introduced during new feature development in recent releases. To suggest that this on its own somehow manifests a more stable jdk compared to some ancient, battle tested version of the jdk is debatable. I find it rather concerning that so many bugs exist to begin with. Why are these not caught sooner? Has the whole world gone crazy? Am I the only one around here who g…

Java has been around for nearly 30 years, I'd hope the core libraries had very few bugs by now.

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

#105

Post by belfthrow »

Brystephor wrote: post #26
larperdoodle wrote: post #21

Earlier quoted context omitted.

Why haven't places updated already? It's not that much work to update. Where I work we always go to the new LTS version as soon as it's supported by gradle. Doesn't cross anyone's mind to _not_ upgrade.

1) dependencies need to be upgraded. for example, not all versions of Gradle support all Java versions. So you need to upgrade Gradle to upgrade Java. 2) other things are deemed to have higher priority. 3) people are satisfied with existing features and don't want to spend energy to upgrade to something that doesn't provide immediate value. 4) folks aren't educated on what the benefit of switching would be so why wou…

1) is garbage. Since grade 6 you can run on 22 ea with no issues. Use toolchains, as they say on their docs.

2) no shit. What business user is every in their mind prioritising upgrading their language version? It's not up to them to push the upgrade. It's yours.

3) of course they are. People don't desire what they don't want. Invest in people who are actually interested in improvement of their software.

4)the java team have been pushing heavily via twitter / youtube / infoq / hacker news / other open jdk providers all the new features for every single java version during their 6 months release cycles. If your devs / your team don't know about it, then maybe again youre not encouraging people to want to improve on what they have, or take interest in the tech they work in.

I mean that is fine, do I give a shit what java version in using for my take home salary? No...but I enjoy using the newest, most interesting and useful tools. And you best believe those people are more attractive to other companies and you working on some 15 year old java 8 tech.

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

#106

Post by statquontrarian »

pron wrote: post #38
tantamounta wrote: post #19

Earlier quoted context omitted.

With the API being nearly the same, I keep just thinking that Virtual Threads are basically identical to Platform Threads except that they use far less memory (so you can have lots more of them). Are there any other actual differences? Better Peformance?

The relationship between throughput, latency, and concurrency in servers is expressed via Little's theorem. If your server is written in the thread-per-request style -- the only style for which the platform offers built-in language, VM, and tooling support -- then the most important factor affecting maximum throughput is the number of threads you can have (until, of course, the hardware is fully utilised). Being able…

That is an absolutely amazing video. From a brief, intuitive, and well-diagrammed explanation of non-trivial concepts of queuing theory, to practical examples, to connecting it all to real-world use cases and value, and all within a surprisingly short period of time, it is one of the most impressive technical videos I've ever seen. Thank you.

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

#107

Post by kevan »

larperdoodle wrote: post #21
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.…

Why haven't places updated already? It's not that much work to update. Where I work we always go to the new LTS version as soon as it's supported by gradle. Doesn't cross anyone's mind to _not_ upgrade.

For an example, my team owns a dozen services and they have hundreds of direct and transient dependencies. Of those, maybe a dozen or two to need work to support the new version but that's a dozen different teams that have to put the work on their roadmap and prioritize it. When the entitlement is 'devs want to use shiny feature X with hard to quantify productivity benefit' it's difficult to prioritize. When there's an efficiency benefit then things move fast because a 10% efficiency improvement means 10% lower server costs and that's easy math.

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

#108

Post by kelnos »

YeBanKo wrote: post #97
papercrane wrote: post #64

Earlier quoted context omitted.

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.

Why would you use virtual threads for CPU heavy loads?

You wouldn't. The GP was illustrating a situation where virtual threads are not a good substitute for native threads.

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

#109

Post by winrid »

winrid wrote: post #93
twic wrote: post #50

Earlier quoted context omitted.

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…

They won't abandon async callback based code. VT have too much memory overhead to be equivalent.

* for high performance stuff

you can still wrap the medium speed/slower stuff in virtual threads.

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

#110

Post by za3faran »

winrid wrote: post #109
winrid wrote: post #93

Earlier quoted context omitted.

They won't abandon async callback based code. VT have too much memory overhead to be equivalent.

* for high performance stuff you can still wrap the medium speed/slower stuff in virtual threads.

Do you have a citation for that? Genuinely curious.
Post reply on HN