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

Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

jvm-weekly.com

Post reply on HN
Print view View original

361–370 of 464 posts

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#361

Post by int_19h »

PaulHoule wrote: post #355
to11mtm wrote: post #254

Earlier quoted context omitted.

I think DotNet had a bit of benefit, in that the language was still new enough to do the hard breakage. It was only about 3.5 years between NET1.0 and 2.0 (Where generics were added.)

I was annoyed by it back when I was doing Silverlight/ASP.NET Thing was a lot of Microsoft APIs for GUIs and whatnot used the List and if you wanted to use the List you had to copy the list or make a wrapper or something. You might say, "just use the List" but at that point (circa 2008) I had to also use the List for some API so I always had to do some conversion.

The way it worked in practice is that all the new built-in collections in System.Collections.Generic implemented the non-generic interfaces as well, so e.g. List implements IList, but it also implements IList (explicitly), and similarly for ICollection and IEnumerable.

Then, when WinForms or WPF wanted a list, you could just give it a List instance, and it would talk to it via IList, boxing and unboxing if necessary.

What you describe happened in the other direction - if you had, say, a generic method operating on IEnumerable or IList, and wanted to pass it a WinForms collection. WinForms generally defined strongly typed collection classes on a case by case basis, but none of them implemented the new interfaces. It was there where you had to wrap things, most often using AsEnumerable().

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#362

Post by rezonant »

Raphael_Amiard wrote: post #268
tzs wrote: post #223

Earlier quoted context omitted.

The first two paragraphs are > On June 15, Oracle engineer Lois Foltan confirmed what a good chunk of the industry had stopped believing: JEP 401: Value Classes and Objects will be integrated into the main OpenJDK repository and is targeting JDK 28. > The change is so large that the remaining committers were asked to hold off on bigger commits during the integration. The pull request alone adds over 197 thousand line…

I mean I’m only answering that because you’re asking, nothing set me off personally there, but now that you ask: « The pull request alone adds over 197 thousand lines of code across 1,816 files. » I noticed that both Claude and GPT are fond of those kind of stupid accounting statements that don’t mean a lot in and of themselves, but look impressive in a « wow numbers » way. Which is kind of ironic since counting rema…

Yeah its definitely inconsistent level of specificity. It's "roughly" 197 thousand files, and yet at that scale a human would call it 200 thousand lines of code, and then an exact count of files at 1,816 instead of a similar level of estimation.

For instance I might write this "The pull request alone adds nearly 200 thousand lines of code spanning almost two thousand files", or even better just "The pull request alone adds nearly 200 thousand lines of code" because really who cares how those are broken up into files.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#363

Post by jayd16 »

ptx wrote: post #293
revetkn wrote: post #229

Earlier quoted context omitted.

Regarding "What's wrong with what .NET did with threads?", see https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html (relevant part below): An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that asyn…

So does Java provide an API for continuations or just the virtual threads hidden behind the threading API? You can't use threads to wait for something on the UI thread (which is why e.g. SwingWorker exists), but you can with await.

Look at their structured concurrency stuff. But IMO it ends up gaining not too much over async/await with worse syntax.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#364

Post by int_19h »

ah1508 wrote: post #181
amitport wrote: post #53

Earlier quoted context omitted.

The mystery of why .NET got so many things right is simply that C# was built several years later by the exact same Microsoft engineers who had previously worked on extending Java, giving them a perfect blank slate to fix the architectural flaws they had already encountered Second mover advantage.

virtual thread instead of async/await is a counter example. Java is more used than C#, they can wait before delivering a new feature (given their leader position) but cannot deliver a flawed implementation that would stay in the language forever. Glad to have virtual threads and the backward compatibility that comes with it instead a Async version of sync methods + async and await keywords all over the code and Task…

.NET had green threads (fibers) in its first iteration. They were abandoned because practical use of .NET was also FFI-heavy - WinForms etc - and native code generally doesn't play well with non-native threads. The benefit of async is that it desugars into callbacks with state, which is something that can be easily expressed in terms of the C ABI (which is the de facto interop standard on all mainstream platforms). Which is why you can have async C# code calling into async C++ or Rust code, or for that matter async Python calling into async C#. Given that .NET was historically supposed to be a multi-language runtime, before they went all in on C#, async made a lot of sense.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#365

Post by egeozcan »

jayd16 wrote: post #359
pron wrote: post #75

Earlier quoted context omitted.

First, your parent comment misunderstood what the section they were critiquing is referring to. It's not about nullability (which is orthogonal) but about reference/value projections. Now, as a member of the Java team (although I'm not directly involved in Valhalla), I'm obviously biased so let me just say that both designers and fans of programming language features would do well to remember two things: 1. Opinions…

This is pretty funny... "All differences are opinions....except what .net did. Those are wrong!" I personally think Java continues to to waste a lot of time and come to a slightly more verbose and worse solution again and again. Structured concurrency is like c# async/await with less sugar. Streams are just LINQ but worse. It's probably exactly because of the "not like .NET! We must be different to explain being late…

As a person with a lot of .NET experience but has been working on other tech since 6 years, the wow effect I had from using LINQ has never been repeated with anything else.

It felt like magic, maybe too much magic, but so useful nevertheless.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#366

Post by parampampam »

jayd16 wrote: post #359
pron wrote: post #75

Earlier quoted context omitted.

First, your parent comment misunderstood what the section they were critiquing is referring to. It's not about nullability (which is orthogonal) but about reference/value projections. Now, as a member of the Java team (although I'm not directly involved in Valhalla), I'm obviously biased so let me just say that both designers and fans of programming language features would do well to remember two things: 1. Opinions…

This is pretty funny... "All differences are opinions....except what .net did. Those are wrong!" I personally think Java continues to to waste a lot of time and come to a slightly more verbose and worse solution again and again. Structured concurrency is like c# async/await with less sugar. Streams are just LINQ but worse. It's probably exactly because of the "not like .NET! We must be different to explain being late…

Nothing funny there. They shared their opinion as an example. Yes it differs from others, that’s what they was talking about.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#368

Post by sroussey »

pron wrote: post #289
mixolydianagain wrote: post #285

Earlier quoted context omitted.

> All of the language differences between .NET and Java fall in this "non-consensus" zone Curious if you think fibers vs async/await is still in this zone (amongst experts). It seems fibers are objectively better. But I'm no expert*

I think user-mode threads are better when the language already has threads . I'm not sure they would have been better for JS. But yeah, this one is probably less controversial than things like properties and extension members, which we also said "yeah, nah" to.

https://github.com/oven-sh/WebKit/pull/249

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#369

Post by txdv »

63 wrote: post #305
devin wrote: post #295

After reading a lot of comments in here, there is one thing that always repeats itself in Java/JVM-related comment sections on HN. There are a surprising number of people who have an idea of what the JVM or Java used to be and have very little idea of what it is today. It is a very fit predator in 2026. Does it have its warts? Yes, but the substrate is extremely good.

Many of us work on Java monoliths that started in the 2000s when it was in vogue and we still have to keep them chugging along on Java 8. Personally I'm familiar with all the new features that have come out in the last few years, but for my actual work, java is literally stuck in the past.

whats keeping you from upgrading?

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#370

Post by im3w1l »

inigyou wrote: post #173
tsimionescu wrote: post #149

Earlier quoted context omitted.

Look at how Go did it. Any value type has a defined 0 value, and any variable of field of that type is initialized to 0 by default. So any un-initialized non-null able value type field could have the corresponding 0 value.

That's worse than null. Now every object has an invalid state. It works for Go because Go is trying to keep language complexity low. It has no good design principles behind it other than that. Also the zero value of a reference is null so you still haven't answered how a non-nullable reference field would work.

I think you should require the code to be written in such a way that the compiler can verify the value is never read before initialization. There might be some subtleties in how to do that but I don't think it should be insurmountable.
Post reply on HN