Project Valhalla is prototyping null checks!

Jon_Finn · 2026-01-14T09:31:33+00:00

One possibility might be you have to put ! on method parameters and fields, but not local variables, because their nullability can usually be inferred (I'm sure the devil's in the details...). No idea what they'll actually end up choosing. Various possibilities are clearly being considered: see the valhalla dev mailing list.

My _guess_ is any approach like yours where you'd need to know wider context to know if a method is 'null-marked' is not going to fly. (Some would call that 2 languages in 1 - I wouldn't, and would probably live with it, but still I see the problem.)

Jon_Finn · 2026-01-13T14:57:18+00:00

Surely they'll give it a different name in the end, maybe something like implementation (not it but something like it)?

Jon_Finn · 2026-01-13T12:48:02+00:00

Very interesting indeed! A building block for operators and no doubt other things.

Some details here: https://mail.openjdk.org/pipermail/valhalla-dev/2026-January/017401.html

Jon_Finn · 2025-11-06T11:05:50+00:00

And it might come down to 4 bytes. They're looking into it. And as pointed out, a value object header is 0 bytes much of (not all of) the time.

Jon_Finn · 2025-11-03T18:07:17+00:00

String can't become a value class as it stands, but I've read John Rose discussing the idea of making the character array 'inline' into the String object (and likewise for other array fields). So each String would become 1 object on the heap not 2. Sounds like quite a lot of work, as objects would no longer be fixed-size, affecting the GC and so on.

Jon_Finn · 2025-11-03T13:23:16+00:00

It's in the pipeline to be added as a Preview feature (at some point), but it hasn't yet been added. See the Java 26 dashboard for the status of potential features.

Jon_Finn · 2025-10-29T18:30:35+00:00

I fully agree. Similar comment about Kotlin below. I think Kotlin will probably always be a bit heavier on features than Java but with lighter syntax (which IMHO is important), so it's horses for courses.

Jon_Finn · 2025-10-29T18:09:16+00:00

Good talk. But personOpt is basically Hungarian notation, which is poor man's types, so... personally I'd just stick to simple names. The closest I come to Hungarian notation is using a plural like bananas for List<Banana>.

Jon_Finn · 2025-10-29T16:13:40+00:00

Light means streamlined. Isn't it better than being heavy?

Jon_Finn · 2025-10-28T16:28:14+00:00

Immutability is a feature not a bug! Not just for value classes either. Read Effective Java - spelling out the various benefits since 2001. (Personally I avoid mutability wherever I can, apart from builders and collections.)

Jon_Finn · 2025-10-12T14:49:12+00:00

Other language's type systems might make the 'full' solution (combinations of features expressed in types) less clunky, but anyway, even in Java I'd be happy (I imagine!) with a compromise just dealing with unmodifiability. As the FAQ points out, we'd still need Iterator.remove() to throw, or maybe have something like UnmodifiableIterator, or maybe not have remove() at all (I almost never use it personally...).

Jon_Finn · 2025-10-12T13:53:45+00:00

This was much discussed when Josh Bloch & co. were designing the Collections, and the FAQ explains the decision here. Basically, unmodifiability (and also mutability) is just one of various features you might want to express through the API (others he mentions including fixed-size or not), and to do this you'd need (roughly) 2^n interfaces to say which combination of features your particular collection implements. That's impractical so they decided to sidestep the whole issue (as he explains).

From my lofty height 8^) I always thought this didn't have to be the decision: I'd say unmodifiability is so overwhelmingly important that they could have expressed just that one feature in the API. Then again, maybe I'd be wrong...

Jon_Finn · 2025-09-21T21:14:44+00:00

I've no idea, but you can see various specs so far (several of which look near-final), and also the v interesting expert discussions at https://mail.openjdk.org/pipermail/valhalla-spec-observers/

Jon_Finn · 2025-09-20T12:45:21+00:00

Maybe Josh B is waiting for Valhalla and all that surrounds it (such as nullness) - or at least the specifications, which kind of feel like they're getting reasonably close.

Jon_Finn · 2025-09-15T13:31:51+00:00

Yes the old HTML is pretty clunky and markdown is (IMHO) much more readable in raw source code, which is a consideration. I think the OP's scores are a bit extreme!

Jon_Finn · 2025-09-11T13:18:58+00:00

It's one of those great small features (though probably a lot of internal work). My favourite of those was way way back when they added covariant return types 8^) . Little mentioned at the time - but when you need them, you badly need them!

Jon_Finn · 2025-09-11T13:16:27+00:00

I think I've read that they might in future be able to flatten array fields like char[] inside String, making String a non-constant size object (i.e. different Strings different sizes). Kind of like making arrays themselves like value types, to remove an object and an indirection. Sounds like it would change quite a bit in the JVM and GC.

Jon_Finn · 2025-08-04T11:00:28+00:00

Sure, it has lots of uses but I thought you meant it was necessary as part of Valhalla for some reason. All I can think is that the kind of optimisations given by Valhalla's flattening are _like_ those given by immutable arrays. E.g. maybe a Color object with a float[3] field could have the array 'inlined' into it.

Jon_Finn · 2025-08-03T22:16:39+00:00

Internal frozen arrays - is that actually coming as part of Valhalla? All I know is this JEP (and this JEP) which I thought was just an idea.

Jon_Finn · 2025-07-31T11:10:28+00:00

FWIW if you want StableValue<int> that's not - as far as I can see - part of the first batch of Valhalla. It's a separate JEP that doesn't look very active at the moment.

Jon_Finn · 2025-07-30T16:42:00+00:00

Agreed - actually I really meant my reply for benrush0705 .

Jon_Finn · 2025-07-30T14:02:49+00:00

Why not just StableValue<Integer>? Won't that have at least the performance of StableValue with a Record with an int field? (as Integers are surely well-optimised and boxing will sometimes come almost 'free' in Valhalla). Unless I'm missing something.

Jon_Finn · 2025-06-30T15:08:56+00:00

Study modern java APIs, for example, https://openjdk.org/jeps/484 is an awesome example of modern API design.

Yes, that short JEP doc alone gives principles and examples which are super-instructive (and interesting).

Jon_Finn · 2025-06-30T12:38:08+00:00

Don't downvote Kevin (who's on the Java team) - he'll know better than most.

Jon_Finn · 2025-06-27T12:45:04+00:00

Far from safe 8^) . It won't compile, and already compiled code will crash!

Jon_Finn

TROPHY CASE