121–130 of 191 posts
Does anyone know if Java virtual threads will also have channels and a select concept, like in Go?
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.
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.
Earlier quoted context omitted.
Not always for sure. We started JDK upgrades with 9 and went +1 every half year and Groovy was lacking with one of 10, 11, 12 or 13. It got so tiring that we had to let it go. Fortunately our tests were mostly JUnit 5, so it wasn't much of work. We only used it for Spock AFAIR.
If you're upgrading every minor Java version, then yeah, I agree Groovy and most other dependencies that may not work on Java version changes off the bat (Lambok, probably Spring and other heavy frameworks like Micronaut and Quarkus, build tools like Gradle... many more) are going to slow you down. You end up with a very simple project if you remove all of that, which is actually a good thing if you can afford doing…
Spring supports new JDK release ("minor version" like you called them, those between 11 and 17 and 21) before release. The only exception was with JDK 13, there was about 2 week slip there.
Lombok (I don't like it) supports every such version at release (not before unfortunately).
Other libs didn't even error out (we keep them at newest versions possible, aside from Jakarta madness).
So from the major libs/frameworks, the only thing that slowed us down was groovy.
(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…
What do you mean by using a file handle, is this a Windows platform thing? On *ix, threads don't use up file descriptors (but you can still have a million fd's at least on linux for other stuff if you want).
We have a hundreds of third party dependencies across the code base, a lot of the big ones (Hibernate, Spring, a lot of Apache). We write a big web application and maintain a big legacy desktop application in Swing.
We run a dedicated nightly CI job that is on the latest Java release to get early warning for any incompatibilities. After the painful migration from 8 to 9 so many years ago it has been smooth sailing.
In all those version upgrades over all those years and dozens of on premise installations with big customers we have never had a regression or a problem that was caused by the runtime itself.
If you're viewing that website on a desktop, I strongly suggest removing max-width: 90ch from the body css. Instead of 50% white space, it goes full width and makes the table substantially more readable (particularly the code samples).
But I tend to use reader mode on most sites anyway because it's an easy way to get rid of banners (cookies, subscription etc.)
Earlier quoted context omitted.
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..
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.
Earlier quoted context omitted.
I really like that Ruby throws NoMatchingPatternError if none of the patterns match. It's a bit like the much-acclaimed exhaustive pattern matching in static languages (though at runtime rather than compile-time, obviously) and better than just silently falling off the end, which IIRC is what Python's pattern matching does.
In Python you can terminate a for loop with else, which will be run whenever the loop runs to the end without breaking
Here's what I mean. The Ruby will throw NoMatchingPatternError and the Python will silently do nothing.
x = [10, "figs"]
case x
in [n, "apples"]
:foo
in [n, "oranges"]
:bar
end
# ---
x = [10, "figs"]
match x:
case [n, "apples"]:
...
case [n, "oranges"]:
...