Java 21: The Nice, the Meh, and the Momentous • Hacker News Board

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

#21

Post by larperdoodle » Fri, Sep 22, 2023, 5:07 PM UTC

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.

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

#22

Post by munk-a » Fri, Sep 22, 2023, 5:07 PM UTC

Someone1234 wrote: post #17

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

Hilariously enough I was initially confused by this comment because the webpage rendered so readably for me - the base CSS is actually quite reasonable and because I have JS disabled by default the page never re-rendered into the thinner mode.

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

#23

Post by noelwelsh » Fri, Sep 22, 2023, 5:09 PM UTC

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?

The context switch time is much smaller, so yes, better performance.

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

#24

Post by krzyk » Fri, Sep 22, 2023, 5:12 PM UTC

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

You forgot about 8->17 which ads really nice language features, records alone are greatest feature after lambdas.

And 21 brings patterns in switch and records.

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

#25

Post by Jtsummers » Fri, Sep 22, 2023, 5:13 PM UTC

mrkeen wrote: post #16

In the code example for virtual threads, I have no idea what will happen in parallel. How do I reason about the order in which the calls change the state of the world?

That's all sequential code, it would be run inside a single "virtual thread". Note that the async code on the right is also sequential, just structured through an async API.

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

#26

Post by Brystephor » Fri, Sep 22, 2023, 5:17 PM UTC

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.

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 would it be prioritized? This is a case of "they don't know what they don't know".

I work on a team using Java 8 daily. It's fine. It's got things I wish it didn't (no null in switch statements for example) but I don't care about that so much that I'm going to go through the pain of upgrading 7-9 services in the mono repo, their dependencies, and then test them all to be on a new version of Java.

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

#27

Post by munificent » Fri, Sep 22, 2023, 5:17 PM UTC

ecshafer wrote: post #2

Java getting better pattern matching is a great change. Id really like more of the functional features to make it into Java. I would love if Java pattern matching could at least get to the level of ruby pattern matching. Ruby pattern matching will allow you to deconstruct arrays and hashes to get pretty complicated patterns, which is really powerful. Right now it seems like Java might have that with a lambda in the p…

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 that Dart doesn't have symbols, so the keys are string literals instead. Also, variable bindings in patterns are explicit (using "var") here to disambiguate them from named constant patterns.

[1]: https://medium.com/dartlang/announcing-dart-3-53f065a10635

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

#28

Post by [deleted] » Fri, Sep 22, 2023, 5:22 PM UTC

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.

[deleted]

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

#29

Post by billfruit » Fri, Sep 22, 2023, 5:24 PM UTC

Does it add stdint style names for integer types, unsigned integer types etc?

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

#30

Post by layer8 » Fri, Sep 22, 2023, 5:30 PM UTC

billfruit wrote: post #29

Does it add stdint style names for integer types, unsigned integer types etc?

The size of the integer types are already fixed by the JVM specification (int is always 32 bits, etc.), and there are no unsigned integer types in Java except for char (a 16-bit unsigned integer type). Furthermore, Java does not support alias names for types. Hence it’s unclear what your question is aiming at.