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

331–340 of 356 posts

Re: Java 20 / JDK 20: General Availability

#331

Post by munificent »

dart_fan wrote: post #275
munificent wrote: post #136

Earlier quoted context omitted.

I work on Dart which is also adding pattern matching [1]. When we designed the syntax for guards, we also considered exactly these three choices before ultimately landing on "when" too. Our main reasoning was: "&&" is intuitive but it means that you can have a pattern that is immediately followed by an infix operator. That can be problematic if you ever want to make "&&" a valid pattern infix operator. And, in our ca…

Very excited to hear this, if true, I will pick up Dart & Flutter again after this is released.

It's very true. If you build the bleeding edge Dart SDK yourself, it's already turned on. It will be enabled in the next upcoming beta release.

Re: Java 20 / JDK 20: General Availability

#332

Post by pjmlp »

jayd16 wrote: post #327
pjmlp wrote: post #297

Earlier quoted context omitted.

Tasks aren't threads in TPL.

What are you trying to say? They still run on threads and can consume them.

They are no different from how Go routines or Java's virtual threads multiplex OS threads per execution path.

In fact, if you feel like doing some advanced stuff, you can write your own schedule algorithm.

Re: Java 20 / JDK 20: General Availability

#333

Post by BlackFly »

tomp wrote: post #317
cozos wrote: post #316

Earlier quoted context omitted.

Can you expand why its a leaky abstraction? Is it because virtual threads can only yield when its doing blocking operations?

Yes. When you're in a "tight loop" (e.g. a matrix multiplication, which is basically 3 nested loops that only load data, do math, write data), Java's virtual threads just won't yield. So if you write your app in the "wrong" way, you lose concurrency. There's a lot of discussion about this from the Go side. The original issue was this one: runtime: tight loops should be preemptible https://github.com/golang/go/issues/…

I doubt it, since they already did that journey long ago and are now adding virtual threads next to ordinary threads that replaced the original green threads. If you put your long running work into the virtual kind of threadpool, a timing sentinel can easily warn you and after noticing that you easily use the normal threadpool instead.

VertX framework had such a sentinel, but migrating code from the async futures to a normal threadpool can be a bit tedious if your design is poor.

Re: Java 20 / JDK 20: General Availability

#334

Post by kaba0 »

severino wrote: post #318
kaba0 wrote: post #190

Earlier quoted context omitted.

M:N is not the interesting aspect of virtual threads at all, automagically turning blocking operations into non-blocking is - which has not really been tried before (with erlang and go being the first).

> M:N is not the interesting aspect of virtual threads at all, automagically turning blocking operations into non-blocking is I'm not very into this Loom virtual threads thing, but... what's the difference between this automagically conversion of blocking into non-blocking in a M:N model and a 1:1 one? I mean, couldn't the same be done with normal threads too?

Well, to a degree this is also done by the OS, IO syscalls are frequent locations where the OS scheduler might decide to schedule another thread, but this is a very slow context switch (flushing caches, including TLB, the switch to kernel mode and back, and since heartbleed and alia it is even more expensive).

Loom implements every IO on top of a more modern async OS calls, and these virtual thread context switches are on the order of function calls, so the overhead and number of switches that can happen are much much lower.

Re: Java 20 / JDK 20: General Availability

#335

Post by nerpderp82 »

kedean wrote: post #324
nerpderp82 wrote: post #272

Earlier quoted context omitted.

You have to provide more context, so that it has something to bridge in the high dimensional space. > The Byzantine Generals Problem is a more difficult problem than the Two Generals Problem because it requires a consensus algorithm that can tolerate the presence of faulty actors. There are many solutions to the Byzantine Generals Problem, including Byzantine Fault Tolerance, which is a common technique used in distr…

You're supporting their point. You can't go to ChatGPT for knowledge you don't already have because it will confidently spout garbage, which is what was being suggested "whats new in java X". If you can build that bridge yourself then you aren't asking it for knowledge, you're asking it to format things for you.

I disagree, I use it all the time for things I don't know about. I then feed those discoveries into semanticscholar, scholar.google.com, wikipeida, libgen.is, etc.

I then ask it so summarize and ELI15. If ChatGPT is feeding you bogus knowledge then you are already consuming bogus knowledge over your existing channels. If you aren't including feedback into your understanding you are recording, not learning.

Re: Java 20 / JDK 20: General Availability

#336

Post by znpy »

exabrial wrote: post #202
znpy wrote: post #13

Does anybody know if there are significant improvement fir java on arm in this release?

Java on my ARM MBP is _very_ fast, by a large margin; faster than my x86 cloud servers by 1.5x-2.5x

Nice, I’ll put your arm laptop in production then

Re: Java 20 / JDK 20: General Availability

#337

Post by taftster »

Floegipoky wrote: post #325
taftster wrote: post #119

Earlier quoted context omitted.

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 want to completely enforce that my record is instantiated with all its invariants dealt with properly Such validation logic can be enforced in the record's compact constructor.

Yes, agreed. But not in a clean "fluent" style. There's something nice about the fluent style that appeals to me (at least).

And I don't like having to provide one constructor for every optional (default) value, when its omitted. There's just not as nice of a style. The "telescoping" constructor pattern is just really hard to use, read and maintain.

Re: Java 20 / JDK 20: General Availability

#338

Post by mike_hearn »

jayd16 wrote: post #328
mike_hearn wrote: post #313

Earlier quoted context omitted.

You can make an async function contain an await at more places than it previously had. When writing code in colored languages your code tends towards lots of stuff being marked async, so more 'await' points being introduced can change behavior.

You're saying something is bad because it could affect a race condition you had? Doesn't everything fall under that issue? That's not changing from invariant to variant.

I'm not saying it's bad, I'm saying that you can still have races and thus still need some form of synchronization even when using async/await. Whilst in simple cases you can preserve invariants just by carefully choosing where an await is done, as things get more complex you constantly run the risk that someone will introduce another await somewhere else (and maybe more async marked functions to enable that), without understanding that the 'await' can now run code that violates some invariants. Locks and other such mechanisms let you mark certain code as executing atomically regardless of scheduling.

Re: Java 20 / JDK 20: General Availability

#339

Post by taftster »

koyote wrote: post #243
taftster wrote: post #130

Earlier quoted context omitted.

Kind of. It gets you close. With the Builder pattern, you can easily define complex relationships for your class inner state. Like maybe if A & B are specified, then C shouldn't be specified. But if C is specified, then D should have a default value. Etc. These types of initialization requirements are not easily duplicated with C# init-only construction. Instead, in C# you have to rely on the callers to know exactly…

Do you have an example of how builders work in Java?

This is probably a pretty good link to start from.

https://blogs.oracle.com/javamagazine/post/exploring-joshua-...

Re: Java 20 / JDK 20: General Availability

#340

Post by cryptonector »

cryptonector wrote: post #330
kaba0 wrote: post #201

Earlier quoted context omitted.

> I think what you probably had in mind is that C libraries of the 90s that did M:N threading didn't turn blocking operations into non-blocking Yes, mostly, though my history knowledge is definitely lacking so do correct me if I’m wrong. But you are right, there was nothing fundamentally missing, probably just no good OS support for non-blocking IO calls in the early days? Though probably the IO-CPU ratio was also di…

There were bad experiences with the M:N threading of the 90s in Solaris' and others' C libraries. Making those libraries make every file descriptor non-blocking behind the programmer's back was a tricky thing. Think about inheritance of file descriptors via fork() and exec() -- you could have one threaded process sharing an FD with a non-threaded process, and now even non-threaded processes' C library would have to p…

Which makes me wonder why this can be done in Java or Erlang, and the answer is that those tend to be walled gardens from which one does not fork/exec.
Post reply on HN