Live data from Hacker News

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

jvm-weekly.com

381–390 of 464 posts

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

#381
post #359
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…

Both languages/runtimes are decent, stable and good choices for running production systems.

They have different philosophies though, C# is mostly "give the developer a complex toolkit so they can do whatever they want, but keep the runtime simple", while Java is more like "keep the language as simple as possible, and put new features mostly into the runtime making it more complex, but benefiting even old code".

Async vs virtual threads is a clear example of that. The former makes the language much more complex, and has a huge surface area where it may clash with other features, so a developer has to remember all of these. But it's a simple machinery under the hood.

Meanwhile virtual threads don't change the language at all, it's the same as it was with Threads, but under the hood it is a very complex feature.

And in this particular instance I think it is quite clear cut that Java made the correct decision, for the most common use case of these languages having non-blocking IO "automatically" makes for significantly better user experience.

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

#382
post #118
post #113

Earlier quoted context omitted.

The problem is how to do it without breaking ABI, 30 years of Maven Central is very relevant, Java isn't doing a Python over value types.

But if you define a new type, how is that breaking backward compatibility?

Well, my old code can have a List, and I can pass my new type into it and have it do some operations. Let alone with reflection - so backwards compatibility is more complex than that.

As for structs, Java avoids e.g. tearing issues with making them immutable, while it is easy to optimize it to local modification under the hood.

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

#383

Earlier quoted context omitted.

> plan to Well wasn't that the argument above, that the stuff they added so far isn't proper at least in part because they didn't fix that problem yet?

> yet But up the comment section, someone thinks they won't be there 'in the future'

The comment that says it won't be there in the near future? That's seems like a reasonable claim to me.

And a promise to eventually fix a busted implementation doesn't undo it being busted for a significant amount of time.

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

#384

wow, basic stuff c++ had since the 80s. congrats. clap, clap, clap. now can someone please make this app that is running with -Xmx360m not use 700mb of resident memory ? asking for a friend.

try reducing the heap size as it seems that's what's eating half of those 700mb

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

#385
post #359

Earlier quoted context omitted.

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.

LINQ comes from FP, and was introduced into C# via Haskell, and actually the first version (.NET 3.5) was quite similar to Smalltalk or Common Lisp collections.

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

#386

Earlier quoted context omitted.

Especially because signed integers aren't symmetrical. Reserve INT_MIN and you get 8 billion NaN values and multiplying by -1 always gives you a valid location.

Ah, INT_MIN. If I had a nickel every time I saw an implementation of inttostr/strtoint that don't properly handle it, I'd probably have about $5. So I too thought about possibility of it serving as a NaN of signed integers... but I doubt we'll see it any time soon. Also, apparently, shifting a negative number to the left is UB in C.

Left shifting a large positive number is also UB. C made a lot of things undefined that would make much more sense as implementation defined.

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

#387

wow, basic stuff c++ had since the 80s. congrats. clap, clap, clap. now can someone please make this app that is running with -Xmx360m not use 700mb of resident memory ? asking for a friend.

What a dumb comment. It's almost like a low-level language having a different feature set is expected.

Also, there is no exact analogue, C++ is just wholly different where you can specify copy/move/destruct semantics on a gradual basis.

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

#388
post #351

> There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent access). I really hope they give an escape hatch for this. It will make it really hard to extract a lot of the benefit of valhala if you can't make a thread unsafe value class. It's also one of those problems that will be quite hard to run into. You basically nee…

I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway? And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)

> I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway?

You can assign the object again to overwrite it 'in place'.

> And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)

They even already have an extra 'null' bit tacked on to the value object.

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

#389
post #88

Earlier quoted context omitted.

But what I don’t get reading the original article is that they present how to insert struct in an object oriented language as an intractable problem, whereas a good implementation with .net (as far as I can tell) has been out there for nearly 30 years. And C# was shameless about stealing from other languages.

Dlang this this before. You have classes and struts, with different semantics.

Unfortunately D will remain a niche language due to various reasons, and is D not Dlang.

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

#390
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.

Most don't even know there are plenty of JVM implementations to chose from.
Post reply on HN