81–90 of 191 posts
What's the Scala community think about this development? I would think this would affect them quite a lot. Google is not helping.
The Typelevel folks on Discord are of the opinion it's not of much interest to them
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.
The services I work on pump the entire business revenue from start to finish. A few nice to haves for devs aren't any where close in the risk calculation if something breaks
Earlier quoted context omitted.
The bigger the project, the more painful the upgrade. Package systems are convenient to avoid reinventing the wheel, until you have to upgrade any piece of it. Then you're stuck trying to figure out which versions of each package go together. If Package A won't run on JDK 17 your entire project is stuck on JDK 11. If Package B is upgraded but has conflicts with Package A, you have to dig through old versions until yo…
"Oh look, I need to upgrade mockito and Spring. Oh, now I upgraded Spring I need to update the spring JPA plugin. Oh now I upgraded that I need to upgrade Hibernate. Oh now I need to upgrade the library built on it that that team over there maintains. Oh, they're not interested." etc. etc.
What's the Scala community think about this development? I would think this would affect them quite a lot. Google is not helping.
It sounds like it has some neat new features. But I'll never know because I'm never again going to use another Oracle thing. There's not a thing they could make that's good enough for me to agree to one of their EULAs and install it. Their behavior in that area is just staggeringly bad.
If you don't trust the Oracle based open source builds then just wait a bit for Microsoft, Redhat, and others to release their version 21 OpenJDK builds that will be found under https://adoptium.net/marketplace/
(1) It's a bit of a bad smell (which he points out) that records aren't being used much at all in the Java stdlib, I wrote something that built out stubs for the 17 and 18 stdlibs and that stood out like a sore thumb. I do like using records though. (2) I've looked at other ways to extend the collections API and related things, see https://github.com/paulhoule/pidove and I think the sequenced collections could have b…
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…
you can avoid both issues by using 20yo executorservice.
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.
This is a niche case, but I spent months trying to upgrade one of our services from one LTS version to the next (I forget which). We encountered a weird bug where services running on the latest JRE would mysteriously corrupt fields when deserializing thrift messages, but only after running for a little while. After an enormously unpleasant debugging cycle, we realized that the JIT compiler was incorrectly eliminating…
The end result of my own investigation led to this quite satisfying thread on hotspot-compiler-dev, in which an engineer starts with my minimal reproduction of the problem and posts a workaround within 24 hours: https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2021...
There's also a tip there: try a fastdebug build and see if you can convert it into an assertion failure you can look up.
Earlier quoted context omitted.
Structured concurrency in JDK 21 is not only a powerful and flexible library feature, but one that is built deep into the runtime in a way that allows observability into the relationships among threads: https://openjdk.org/jeps/453
Do you know if clojure will be adopting these virtual threads, or still using the macro-based approach?
You could always set the backing thread pools for core.async and agents in Clojure. That gives you the ability to use virtual threads right now.
But in order to avoid thread pinning, there will need to be some code changes to convert some uses of synchronized to ReentrantLock. How fast that happens will depend upon the given library maintainer. Here's an issue for making some of these changes in Clojure's core library: https://clojure.atlassian.net/browse/CLJ-2771
I've tested Clojure's agents with the new virtual threads for my targeted use case they're significantly faster than before - I can spin up tens of thousands of mostly idle agents and reach performance close enough to core.async for me.
Earlier quoted context omitted.
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…
I watched the video and thoroughly enjoyed it, thank you for sharing it! I have a question that is perhaps not entirely related to the video, but it touches the topic of context switches. I've read this post [1] by Chris Hegarty, which explains that when calling the traditionally blocking network I/O APIs in the Java stdlib from a virtual thread, it uses asynchronous/poll-based kernel syscalls (IOCP, kqueue, epoll on…
Yes.
> Does Java Virtual Threads do the same, or does disk I/O block the carrier threads? For curiosity, does Java file APIs use io_uring on Linux if it is available?
We're working on using io_uring where available, especially for filesystem IO. For now, filesystem IO blocks OS threads but we temporarily compensate by increasing the size of the scheduler's worker thread pool.