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

251–260 of 356 posts

Re: Java 20 / JDK 20: General Availability

#251

Post by anyfoo »

hn_throwaway_99 wrote: post #59
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…

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

> While it's not a boolean expression per Java, at least in my mind it serves the same purpose

But if some construct looks the same, but is not the same, and worse, only "somewhat" the same, you get confusing behavior. At least for newcomers, or even just software engineers who just don't care about language grammar that deeply (which I imagine are not only a lot, but also a lot of the Java target audience specifically).

Case in point, the author I was replying to wondered in a followup whether && would/should still act like a shortcut-and operator would, or not.

There is definitely some subjectivity to it, but personally I much prefer if different constructs look clearly different. Any ambiguity is squashed immediately, and in the case of "when" it's still fully clear how it works. I'm also okay with the "if" variant, because while it reuses a keyword, it's clearly a different "if".

Re: Java 20 / JDK 20: General Availability

#252

Post by jgon »

taftster wrote: post #119
desertlounger wrote: post #115

Earlier quoted context omitted.

Yes. And with "records" (record classes, something with the characteristics of a tuple or struct) you can get further away from getter/setter boilerplate code.

I just wish records had an easy way to facilitate and/or associate a builder with them. Wishful thinking, out of scope for what they are. And of course, it's not hard to write a FooBuilder that's defined to help construct a Foo record. If Java records could be told to have a private constructor, I'd be completely satisfied with them. I just don't like the ability for callers to be able to directly instantiate a recor…

I wanted to experiment with creating a "Rust-like" option and result type for Java and so figured that I would need records and pattern matching for this and I ran into exactly what you are talking about here with records and public constructors.

My solution was to create a sealed interface that permitted the None and Some records as the only classes to implement it. Those records are not available outside the package, while the interface is exposed. Using default methods in the interface I could expose a state "create()" method which would then instantiate the appropriate None or Some record. In this way you control the exposure of the construction of the specific record implementations of your interface.

You can then either interact with the option through the methods on the interface, .isOk(), .unwrap(), etc, etc, or with the upgraded pattern matching in switches with this release you could have something like

  switch(option) {
    case option when option.isNone() -> blah
    case option when option.isSome() -> foo
}

Its not as pleasing as Rust matching directly on Some and None, but it gets you pretty close.

Re: Java 20 / JDK 20: General Availability

#253

Post by DannyBee »

foolfoolz wrote: post #48

its amazing how much the world hasn’t been able to keep up with java. github PRs still have no syntax highlighting support for record and var

It's highly amusing to watch java folks frame this as the rest of the world not "keeping up" when it's pretty obvious it's the rest of the world not caring enough to do anything about it.

I wonder how long it will be before they realize they are in the slow, sad, decline regardless of how many features get added.

Re: Java 20 / JDK 20: General Availability

#254

Post by Holo314 »

jillesvangurp wrote: post #205
philonoist wrote: post #87

Could the pundits of HN please compare this release with Kotlin?

Picking the release notes apart: - ScopedValue (Incubator). Seems like a replacement for ThreadLocal that is intended to be a bit less dangerous (it is notorious for leaking memory and file handles). The Kotlin equivalent would be CoroutineScope. I'd say the latter is the cleaner solution. And probably ScopedValues came into existence for the same reason (co-routines & structured concurrency kind of breaking ThreadLo…

- ScopedValue doesn't have a direct equivalent in Kotlin, but CoroutineContext.Element and ThreadContextElement inside of CoroutineContext serve the same purpose. I really think Kotlin overcomplicated this idea.

- Record Patterns are stronger than Kotlins smart cast because of nested patterns

- Kotlin Coroutines works exclusively with Structured Concurrency already. The JEP just adds a way to use Structured Concurrency with threads (it can also be used in Kotlin if you use pure Threads(virtual or not), but I don't see any reason not to use Coroutines

Re: Java 20 / JDK 20: General Availability

#255

Post by Holo314 »

Traubenfuchs wrote: post #37

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

Virtual threads are designed for light, IO-bound, tasks, if your task is heavy/CPU-bound tasks then you won't necessarily want to switch to virtual threads with ScopedValue.

Re: Java 20 / JDK 20: General Availability

#256

Post by oulu2006 »

digitalsanctum wrote: post #144

As an engineer that last used Java when it was Java 11, I cringe at the thought of diving back in. A trade-off of increased release velocity for any language I suppose.

I use Clojure, which benefits from these consistent JVM improvements; things like pattern matching have been accessible to me for years already, but I like that Java slowly trails along as it helps keep me vested in the Java ecosystem.

Re: Java 20 / JDK 20: General Availability

#257

Post by coldtea »

Legion wrote: post #229
mongol wrote: post #177

Earlier quoted context omitted.

Boring answer... but Chat GPT? I asked it what was new in Java 8 and it enumerated a number of features. I could proceed to ask it about more details for each, and then continue Java version by version and I think it would be quite exhaustive. The other day I did something similar for cell biology. As a layman I wanted to learn more about DNA, mRNA, tRNA, translation, transcription, mitosis, miosis, etc. I think I le…

The problem with ChatGPT is that, when it should say "I don't know", it will instead confidently spew plausible sounding garbage.

So, like most people?

Re: Java 20 / JDK 20: General Availability

#258

Post by Holo314 »

taftster wrote: post #119
desertlounger wrote: post #115

Earlier quoted context omitted.

Yes. And with "records" (record classes, something with the characteristics of a tuple or struct) you can get further away from getter/setter boilerplate code.

I just wish records had an easy way to facilitate and/or associate a builder with them. Wishful thinking, out of scope for what they are. And of course, it's not hard to write a FooBuilder that's defined to help construct a Foo record. If Java records could be told to have a private constructor, I'd be completely satisfied with them. I just don't like the ability for callers to be able to directly instantiate a recor…

Java is built upon it's community :), look no further: https://github.com/Randgalt/record-builder, although hiding the constructor behind the builder is not something I am sure supported by that library

I also remember a discussion in the mailing list about withers: https://mail.openjdk.org/pipermail/amber-spec-experts/2020-M...

Not sure where it stands now, you can ask in the mailing list about this

Re: Java 20 / JDK 20: General Availability

#259

Post by lmm »

anyfoo wrote: post #38
mason55 wrote: post #28

Earlier quoted context omitted.

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

Java has two gramatically different forms of "try" in a similar fashion (one with parantheses and one without), I don't think this would be any worse than that.

Re: Java 20 / JDK 20: General Availability

#260

Post by xyzzy4747 »

DannyBee wrote: post #253
foolfoolz wrote: post #48

its amazing how much the world hasn’t been able to keep up with java. github PRs still have no syntax highlighting support for record and var

It's highly amusing to watch java folks frame this as the rest of the world not "keeping up" when it's pretty obvious it's the rest of the world not caring enough to do anything about it. I wonder how long it will be before they realize they are in the slow, sad, decline regardless of how many features get added.

I think this is true for young companies - for example every crypto startup I’ve interacted with makes their backend in either Node.js, Golang, or Rust.

There is quite a lot of legacy software that uses Java though.

Post reply on HN