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

131–140 of 191 posts

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

#131

Post by thfuran »

pron wrote: post #91
cogman10 wrote: post #68

Earlier quoted context omitted.

It's somewhat unfortunate that structured concurrency ended up being a preview feature in 21. I agree that it's a great addition but man it'd be nice if it made the LTS. As it stands, probably won't be heavily used until Java 25.

Organisations that care about new features need to reconsider their stance on using Preview features and even more importantly sticking to versions for which the sales org offers an LTS service. The whole concept of LTS is designed for companies that are so uninterested in new features (often because their software is no longer heavily maintained) that they're willing to pay money not to receive them. There are a lot…

That seems like a bad faith interpretation. Upgrading has both costs and risks. Even upgrades within the same major version can break things. LTS is about paying for stability, not a lack of features.

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

#132

Post by thfuran »

fulafel wrote: post #125
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…

You could easily have a million threads if you use multi-kb stacks. Million times multi-kb means multi-gb, that's still 3-4 orders of magnitude less than big memory servers/VMs. (and 1 order of magnitude less than a normal laptop) 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 s…

But "multi-kb" in this context probably actually means about 1MB.

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

#133

Post by fulafel »

thfuran wrote: post #132
fulafel wrote: post #125

Earlier quoted context omitted.

You could easily have a million threads if you use multi-kb stacks. Million times multi-kb means multi-gb, that's still 3-4 orders of magnitude less than big memory servers/VMs. (and 1 order of magnitude less than a normal laptop) 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 s…

But "multi-kb" in this context probably actually means about 1MB.

What do you base this on? The stacks and kernel bookkeeping shouldn't use nearly this much at least on linux. Keep in mind that thread stacks have are lazily allocated virtual memory so won't use as much physical memory as the thread stack size setting shows.

If these threads are handling TCP connections and L7 protocol processing on top, you're going to have nontrivial both kernel and userspace memory usage per connection too that may dwarf the thread overhead.

Here's a linux kernel dev (Ingo Molnar) benchmarking Linux in 2002 and starting just shy of 400k threads in 4 GB: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html - though on a 32 bit systems lots of objects things are 50% the size compared to current 64 bit. But still gives you a ballpark.

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

#134

Post by Macha »

ivan_gammel wrote: post #123
Macha wrote: post #48

Earlier quoted context omitted.

"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.

When using Spring Boot you usually update just one version and everything else is updated via BOM. There should be a really good reason to have fine-grained control over every single dependency.

Not every app using Spring is using Spring boot

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

#135

Post by pron »

thfuran wrote: post #131
pron wrote: post #91

Earlier quoted context omitted.

Organisations that care about new features need to reconsider their stance on using Preview features and even more importantly sticking to versions for which the sales org offers an LTS service. The whole concept of LTS is designed for companies that are so uninterested in new features (often because their software is no longer heavily maintained) that they're willing to pay money not to receive them. There are a lot…

That seems like a bad faith interpretation. Upgrading has both costs and risks. Even upgrades within the same major version can break things. LTS is about paying for stability, not a lack of features.

Well, yes, but in the past the versions that now get a new integer number (feature releases) were mandatory for everyone and there was no LTS at all. There were some differences, but not as big as many think. The biggest one was the psychological aspect of the name (7u4 or 8u20, which were not patch releases but big feature releases).

So why did we create the LTS service? 1. Because the new feature releases, while no more risky than the old ones (like 7u4 and 8u20), do require a little more work that companies don't want to put into legacy applications, and 2. Many companies indeed are willing to pay for more stability for their legacy apps.

So while it is absolutely true that some projects want better stability, this level of stability is new. Companies that religiously stick to old versions now didn't do that in the past. The simplest explanation is that the new release model isn't yet understood, not that thousands of companies changed their risk strategy.

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

#137

Post by pron »

riku_iki wrote: post #102
pron wrote: post #101

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

Then you either don't get the same scalability that virtual threads give you or you get it but with asynchronous code that requires not just more work but can't enjoy the same observability/debuggability on the Java platform.

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

#138

Post by dingi »

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.

On topic of upgrades, here are a couple of tricks I've learned throughout the years which make the upgrade process easier.

1. Use Maven 2. Use BOMs to manage related dependencies 3. No lombok

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

#140

Post by krzyk »

NovaX wrote: post #95
krzyk wrote: post #34

Earlier quoted context omitted.

Gradle/groovy is a liability for any jdk upgrades (similarly like lombok, but it usually supports new JDK at release, not before). We ditched spock because of groovy, and never looked back. Now at jdk 21, previously at 20.

Kotlin, not Groovy, has been the culprit for slower Gradle support. I believe there was some split module pain in Groovy wrt Java 9, but it has been very smooth since then. The Kotlin compiler on the other hand is not very forgiving. This is a moot point because your the build execution and the project compile/run can be on different JDKs. It is a tiny amount of configuration to decouple them, e.g. to use an EA build…

Yeah, you are right that decoupling build tool JDK and compile JDK is the way to go.

But Groovy does indeed not work, or has support very late for releases between 8, 11, 17 and 21 - so for anyone that wants to stay current (and not wait 3 or 2 years), using groovy in your code will be a pain - that might be also possible for other JVM languages, but I don't know, haven't used them.

Post reply on HN