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

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

#11

Post by bcrosby95 » Fri, Sep 22, 2023, 4:21 PM UTC

marginalia_nu wrote: post #9

> Miscellaneous new methods -- meh Dunno, several of these are tangible QoL boosts: Math.clamp(), List.reversed(), List.addFirst(), List.addLast(), Character.isEmoji()

> List.reversed(), List.addFirst(), List.addLast()

These fall under sequenced collections, not "miscellaneous new methods".

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

#12

Post by marginalia_nu » Fri, Sep 22, 2023, 4:22 PM UTC

bcrosby95 wrote: post #11

marginalia_nu wrote: post #9

> Miscellaneous new methods -- meh Dunno, several of these are tangible QoL boosts: Math.clamp(), List.reversed(), List.addFirst(), List.addLast(), Character.isEmoji()

> List.reversed(), List.addFirst(), List.addLast() These fall under sequenced collections, not "miscellaneous new methods".

I guess? I found them under the API diff linked as "miscellaneous new features".

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

#13

Post by Jtsummers » Fri, Sep 22, 2023, 4:26 PM UTC

unregistereddev wrote: post #3

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…

Pattern matching is a neat tool to keep in the toolbox. When it's the right tool for the job, it is really cool and is a lot cleaner than a bunch of conditional checks. However, I rarely reach for it. Maybe my use cases are unusual? I am genuinely curious how often other developers find pattern matching to be the best tool for the job.

When available, I pretty much always use pattern matching. It tends to shorten code while not reducing clarity (often increasing it) which means fewer opportunities for errors to creep in. Statically typed languages that can detect incomplete case handling also reduces the chances for some errors (as long as you don't make a catch-all case) but also helps when you change something so that a new case is needed. It also tends to shift the code to the left, reducing the indentation. So shorter, clearer, less unnecessary indentation. Generally a positive.

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

#14

Post by baq » Fri, Sep 22, 2023, 4:27 PM UTC

  > "Hello, World!".splitWithDelimiters
  >      ("\\pP\\s\*", -1)
  >  // ["Hello", ", ", "World", "!", ""]

> Meh

My brain just melted.

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

#15

Post by weatherlight » Fri, Sep 22, 2023, 4:30 PM UTC

unregistereddev wrote: post #3

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…

Pattern matching is a neat tool to keep in the toolbox. When it's the right tool for the job, it is really cool and is a lot cleaner than a bunch of conditional checks. However, I rarely reach for it. Maybe my use cases are unusual? I am genuinely curious how often other developers find pattern matching to be the best tool for the job.

In languages that have strong support for pattern matching, whether it be on values or types, I find myself reaching for it instead of conditionals. It's all about the explicitness for me. You have to list out all the cases you care about, so there's no room for ambiguity. Plus, the compiler will usually warn you if you've missed a case, which is like a built-in bug catcher. It's also great for working with immutable data, less state to worry about. And let's talk about readability; the code basically documents itself because you can see the shape of the data right in front of you. You can even destructure data on the fly, pulling out exactly what you need. If you're using a statically-typed language, pattern matching adds an extra layer of type safety. And, not to forget, it nudges you toward a more functional style of coding, which I find leads to cleaner, more modular code. So yeah, I reach for pattern matching quite a bit; it often feels like the right tool for the job.

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

#16

Post by mrkeen » Fri, Sep 22, 2023, 4:53 PM UTC

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?

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

#17

Post by Someone1234 » Fri, Sep 22, 2023, 4:53 PM UTC

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

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

#18

Post by waynesonfire » Fri, Sep 22, 2023, 4:58 PM UTC

> Over 10,000 bug fixes

Most of which were likely introduced during new feature development in recent releases. To suggest that this on its own somehow manifests a more stable jdk compared to some ancient, battle tested version of the jdk is debatable.

I find it rather concerning that so many bugs exist to begin with. Why are these not caught sooner?

Has the whole world gone crazy? Am I the only one around here who gives a shit about quality? Mark it zero!

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

#19

Post by tantamounta » Fri, Sep 22, 2023, 5:00 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.…

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?

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

#20

Post by pron » Fri, Sep 22, 2023, 5:02 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.…

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