Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 20 / JDK 20: General Availability

mail.openjdk.org

Post reply on HN
Print view View original

31–40 of 356 posts

Re: Java 20 / JDK 20: General Availability

#32

Post by bcrosby95 »

garblegarble wrote: post #10

This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't see the benefit of introducing a new keyword over using "if"... or even just "&&". To pinch the example used in[1]: case Tuner t && guitar.isInTune() -> ...; and case Tuner t if guitar.isInTune() -> ...; both seem as clear as case Tuner t when guitar.isInTune()…

In 2nd preview, they used &&: https://openjdk.org/jeps/420

At 3rd preview, they switched to when: https://openjdk.org/jeps/427

In that JEP they state:

> Based upon experience and feedback we propose instead to allow when clauses in switch blocks to specify guards to pattern labels

So I assume people thought && was confusing.

Re: Java 20 / JDK 20: General Availability

#34

Post by anyfoo »

garblegarble wrote: post #10

This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't see the benefit of introducing a new keyword over using "if"... or even just "&&". To pinch the example used in[1]: case Tuner t && guitar.isInTune() -> ...; and case Tuner t if guitar.isInTune() -> ...; both seem as clear as case Tuner t when guitar.isInTune()…

The “&&” one is bizarre, it makes it look like the whole thing is a Boolean expression, which it absolutely is not. That gets even weirder because the part right of it actually is a Boolean expression, so on top of very confusing reading you now make it look like there are strange interactions with operator precedence. Using && is one of the worst choices.

The “if” one does not suffer from any such problem and reads okay to me. I guess one argument against it could be that since the whole thing is a distinct grammatical construct, why not just introduce a distinct keyword instead of making an existing keyword depending on context? That’s mostly a question of style though (e.g. I don’t know right now if Java already has an habit of reusing keywords like that).

Re: Java 20 / JDK 20: General Availability

#37

Post by Traubenfuchs »

I still don't understand what's the correct way to replace thread locals holding initialization heavy & non thread-safe instances besides using a pool which produces a lot of overhead when using loom/virtual threads. In the past, with ThreadLocal, you'd have one instance per thread, making sure that those instances could only be used once and would only be instantiated for all threads of your (acceptor) thread pool

Does anyone know the solution?

Re: Java 20 / JDK 20: General Availability

#38

Post by anyfoo »

mason55 wrote: post #28
garblegarble wrote: post #10

This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't see the benefit of introducing a new keyword over using "if"... or even just "&&". To pinch the example used in[1]: case Tuner t && guitar.isInTune() -> ...; and case Tuner t if guitar.isInTune() -> ...; both seem as clear as case Tuner t when guitar.isInTune()…

In the case of &&, the left hand side of the expression (Tuner t) isn't a boolean expression. In the case of "if", you're right, the grammar doesn't work, both because the syntax of Java already says that the if condition must be enclosed in parentheses and also because an if block is a statement and you need an expression here. To make either of those work, you'd have to make the rest of the pattern matching syntax…

The “&&” one is super confusing indeed, but the “if” one is just a question of style. It would be possible to reuse the “if” keyword for different grammar. python does it for its trinary operator, where there is an expression instead of a statement after “then” (e.g. “foo = if bar then 1 else 2”), but if Java does not have the same habit of reusing keywords already (not sure), it might not want to start now for consistency.

Re: Java 20 / JDK 20: General Availability

#39

Post by [deleted] »

bcrosby95 wrote: post #32
garblegarble wrote: post #10

This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't see the benefit of introducing a new keyword over using "if"... or even just "&&". To pinch the example used in[1]: case Tuner t && guitar.isInTune() -> ...; and case Tuner t if guitar.isInTune() -> ...; both seem as clear as case Tuner t when guitar.isInTune()…

In 2nd preview, they used &&: https://openjdk.org/jeps/420 At 3rd preview, they switched to when: https://openjdk.org/jeps/427 In that JEP they state: > Based upon experience and feedback we propose instead to allow when clauses in switch blocks to specify guards to pattern labels So I assume people thought && was confusing.

[deleted]
Post reply on HN