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

51–60 of 356 posts

Re: Java 20 / JDK 20: General Availability

#51

Post by pshirshov »

quectophoton wrote: post #42
pshirshov wrote: post #20

> structured concurrency That's another huge effort which delivered us an imperfect abstraction. I would prefer to have HKTs and typeclasses, so I may implement my own IO monad.

> I would prefer to have HKTs and typeclasses, so I may implement my own IO monad. I'm not a Java developer, and I haven't even read about higher kinded types or typeclasses (the theory side of programming is my weakness); but you picked my curiosity with this. Can you elaborate how concurrency done this way would look in Java?

Ideally like this: https://zio.dev/reference/#concurrency

Or this: https://hoogle.haskell.org/?hoogle=fork

Re: Java 20 / JDK 20: General Availability

#54

Post by garblegarble »

anyfoo wrote: post #34
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…

The "&&" approach is how you express that same logic in an if statement in Java today.

Given this pattern matching syntax change, you'd write:

    switch(obj) {
        case Tuner t when guitar.isInTune() -> ...;
        ...
    }
For a switch, but for an if statement it's written as:

    if (obj instanceof Tuner t && guitar.isInTune()) {
        ...
    }
Edit: I do wonder, actually, if avoiding "&&" is to allow the "when" case execution to be reordered (e.g. to allow JIT to extract common "when" conditions prior to the switch expression), which would be wrong to do given the short-circuiting rule implications of "&&"

Re: Java 20 / JDK 20: General Availability

#55

Post by pansinghkoder »

philipwhiuk wrote: post #27
pansinghkoder wrote: post #18

Earlier quoted context omitted.

You are right; lets start a linux kernel in rust. Send me a PR for that bootloader.

There are bits of the Linux Kernel in Rust.

Like I have tic-tac in my car but its not driving the engine.

Re: Java 20 / JDK 20: General Availability

#56

Post by jackworks »

Waterluvian wrote: post #29
akavi wrote: post #26

Now even Java has pattern matching, what's Javascript's excuse? Literally the only feature preventing Typescript from being my perfect language.

https://github.com/tc39/proposal-pattern-matching I'm not sure if it's stalled or not. But it's being discussed.

We're still developing this proposal. be patient LOL

Re: Java 20 / JDK 20: General Availability

#57

Post by shagie »

pron wrote: post #46
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()…

This year. Six months from today.

(just on the following up on this)

https://en.wikipedia.org/wiki/Java_version_history

The non-LTS releases are every 6 months and have support for one year.

LTS releases are every 4th release which falls on odd numbered years in September.

Re: Java 20 / JDK 20: General Availability

#58

Post by BiteCode_dev »

akavi wrote: post #26

Now even Java has pattern matching, what's Javascript's excuse? Literally the only feature preventing Typescript from being my perfect language.

Given the terrible result we came up with in the Python community, I understand the JS wants to take their time. It's a great feature, but it's hard to get right, especially on an existing language.

Not to mention JS is not typed, but pattern matching that can't match typescript types would be terrible.

Re: Java 20 / JDK 20: General Availability

#59

Post by hn_throwaway_99 »

anyfoo wrote: post #34
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…

As another comment mention, they did use && in the 2nd preview, but then switched it, so you're right, it must have been confusing.

FWIW, though, I don't find it "bizarre". While it's not a boolean expression per Java, at least in my mind it serves the same purpose: "in the case that thing x is of type SomeType and ...some other thing about ((SomeType)x) is true...".

I think it's a tough choice, I'm sure they were probably not wanting to add a new keyword, but at the end of the day "when" is so familiar to anyone who's ever written SQL (which I'm guessing is most Java devs) so seems like a good choice.

Re: Java 20 / JDK 20: General Availability

#60

Post by pajko »

mikepurvis wrote: post #45
anyfoo wrote: post #34

Earlier quoted context omitted.

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…

I'm not a Java user, but I really don't love the overloading of `if` in Python (statement, ternary, comprehensions), so introducing a new keyword here seems pretty reasonable to me. And don't even get me started on `static` in C++.

OK, no static then, but what about if constexpr (...) ? :D
Post reply on HN