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

Re:Project Valhalla, Explained: How a Decade of Work Arrives... by jmyeet on Friday June 19, 2026 @08:27AM (#48597804)

The type erasure version of this would look a lot like Hack [1]. So generic arguments would simply have a ? if they allow nulls eg List<?Point>. The list itself couldn't be null unless it was ?List<?Point>.

Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List<Point> if you're so inclined because the JVM doesn't know the difference, hence type erasure. So this is no different.

I'm no JVM expert but from reading the article it seems like the chosen solution for value classes is to treat them all as a single L-type in the JVM where each primitive type is its own L-type. If I read the correctly, it means that if you have a Point value class then on the JVM level you'll be able to stuff any value class into there if you're so incline, just like with List<Point>.

Obviously we need to be concerned with fuzzing (moreso in C++) but here really we're just trying to have sensible defaults that aren't guaranteed because we can't design the language how we want from the ground up without making a new language.

Oh and there is a prosopal for this [2]. Personally, I prefer the Hack version.

[1]: https://docs.hhvm.com/hack/types/nullable-types/

[2]: https://openjdk.org/jeps/8303099

[ Parent | on HN ]

Re:Project Valhalla, Explained: How a Decade of Work Arrives... by inigyou on Friday June 19, 2026 @09:15AM (#48598213)

you seem to have ignored the question and answered a completely different one

[ Parent | on HN ]

Re:Project Valhalla, Explained: How a Decade of Work Arrives... by kuhsaft on Friday June 19, 2026 @11:43PM (#48606173)

> Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List<Point> if you're so inclined because the JVM doesn't know the difference, hence type erasure.

And that's a massive problem that they're planing to solve with specialized generics. The blog post does a pretty high level overview of it, but my understanding of it is the following:

1. They are adding a new bytecode class flag for value classes.

2. Primitive wrapper classes will become value classes.

3. Parameterized container classes will be flagged with a new bytecode to enable parametric attributes on initialization with additional data of the parameters in the Constant Pool.

4. Initialization of parameterized classes are done with additional metadata of the type argument stored in the Constant Pool.

5. The runtime does monomorphization of the parameterized class.

It doesn't seem too different to what the CLR does, i.e. runtime monomorphization. The difference is that the JVM implementation is backward compatible with older type-erased code, i.e. the restrictions in Java due to type-erasure are exactly the same as before. It's just additional metadata added to allow the JVM to monomorphize the classes.

[ Parent | on HN ]

Re:Project Valhalla, Explained: How a Decade of Work Arrives... by kuhsaft on Saturday June 20, 2026 @02:16AM (#48606811)

All that to be bytecode backwards compatible, although behaviorally there are some breaking changes. See https://news.ycombinator.com/item?id=48597943

[ Parent | on HN ]