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

91–100 of 191 posts

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

#91

Post by pron »

cogman10 wrote: post #68
pron wrote: post #20

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

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 of such projects around, and the fact that non-legacy projects choose old versions and an LTS service shows that the ecosystem still hasn't adapted to the new release model.

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

#92

Post by yCombLinks »

jabradoodle wrote: post #83
yCombLinks wrote: post #37

Earlier quoted context omitted.

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

Sounds like code that's worth learning how to test.

I know right. Unfortunately with jdk upgrades only e2e tests have much value, and those are much more expensive

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

#93

Post by winrid »

twic wrote: post #50
PaulHoule wrote: post #36

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

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

#95

Post by NovaX »

krzyk wrote: post #34
Brystephor wrote: post #26

Earlier quoted context omitted.

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…

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.

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

#96

Post by Mawr »

tantamounta wrote: post #19
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.…

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?

"With the currency being the same, I keep thinking a salary of $50k/year is the same as that of $500k/year. Are there any other actual differences?"

Just as with performance improvements [1][2][3][4], the actual impact on the user experience is non-linear and often hard to predict. In the case of virtual threads, you go from needing to consciously work around a limited amount of available threads to spawning one per request and moving on.

[1]: https://youtu.be/4XpnKHJAok8?t=3026

[2]: "These tests are fast enough that I can hit enter (my test-running keystroke) and have a response before I have time to think. It means that the flow of my thoughts never breaks." - https://news.ycombinator.com/item?id=7676948

[3]: https://news.ycombinator.com/item?id=37277885

[4]: "Go’s execution tracer has suffered from high overhead since its inception in 2014. Historically this has forced potential users to worry about up to 20% of CPU overhead when turning it on. Due to this, it's mostly been used in test environments or tricky situations rather than gaining adoption as a continuous profiling signal in production." - https://blog.felixge.de/waiting-for-go1-21-execution-tracing...

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

#97

Post by YeBanKo »

papercrane wrote: post #64
yankput wrote: post #60

Earlier quoted context omitted.

Virtual threads are strictly better than normal threads, no? I am thinking of any reason to still use traditional threads. Is there any downside?

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?

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

#98

Post by munificent »

brabel wrote: post #46
munificent wrote: post #27

Earlier quoted context omitted.

We recently added pattern matching to Dart [1], so I'm always keen to see how it compares to similar features in other languages. In case it's interesting, here's that Ruby example ported to Dart: print(switch ({'name': 'John', 'friends': [{'name': 'Jane'}, {'name': 'Rajesh'}]}) { {'friends': [{'name': var firstFriend}, ...]} => "matched: $firstFriend", _ => "not matched" }); Pretty similar! The main differences are…

> We recently added pattern matching to Dart [1] I've been using that and I love it, in general... but can I ask you why do we need to name a variable in a pattern like this: switch (p) { Person(name: var name) => ... } That's the only thing that feels a bit annoying as you have to rename the variable... In Java, this would be something like: Person(var name) -> ... EDIT: I guess it's to support `Person(name: 'litera…

We require "var" before variable patterns because we also allow named constants in patterns (which match if the value is equal to the constant's value):

    const pi = 3.14; // Close enough.

    switch (value) {
      (pi, var pi) => ...
    }
This case matches a record whose first field is equal to 3.14 and binds the second field to a new variable named "pi". Of course, in practice, you wouldn't actually shadow a constant like this, but we didn't want pattern syntax to require name resolution to be unambiguous, so in contexts where a constant pattern is allowed, we require you to write "var", "final", or a type to indicate when you want to declare a variable.

Swift's pattern syntax works pretty much the same way.

> > Dart doesn't have symbols

> That's weird, as I actually use sometimes `#sym` (which has type `Symbol`)??

Oh, right. I always forget about those. Yes, technically we have symbols, but they are virtually unused and are a mostly pointless wart on the language. It's not idiomatic to use them like it is in Ruby.

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

#99

Post by coldtea »

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.

Other workplaces have more long term supported systems, with more complex requirements, and more SLAs and guarantees to fulfil.

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

#100

Post by YeBanKo »

yCombLinks wrote: post #79
anonymousDan wrote: post #72

Can anyone explain this comment: "In the past, a thread pool didn't just throttle the incoming requests but also the concurrent resources that your app consumed. If you now accept many more incoming requests, you may need other ways to manage resource consumption."

Yeah, if your server maxed out at 256 system threads you didn't have to worry about the fact that 1024 simultaneous calls would crash your DB. But now you're not limited by system threads

You can still use connection pool + platform threads. Or executor with virtual threads and semaphores or blocking queues. It’s mostly a concern for someone who implements a connection pool, for most devs it’s gonna be the same config option of max connection, that you need to pay attention to.

Any modern web app already has multiple instances of the app querying a db, so you have to keep a tally of total connection number either way.

Post reply on HN