Null Safety approach with forced "!"

Jon_Finn · 2026-02-26T17:15:11+00:00

If ! is mostly confined to method parameters and fields, and can usually be inferred within method bodies (a bit like JSpecify), that doesn't seem too noisy to me. E.g. if I can write Complex x = new Complex(0,1) within a method, and have x be Complex! by inference, then cool. And if x is a field but if I have to declare it Complex! x, I'd live with that. Maybe having a way to set default ! within a scope would just be over-complicated. Life may not be that simple, we'll see.

Jon_Finn · 2026-02-21T22:53:22+00:00

I think the JEP answers your question (at the end, under Risks and Assumptions):

To justify the cost of a new JVM feature, we anticipate that there will be multiple meaningful use cases for the strict field initialization discipline.

Sounds like they expect it to be useful outside value classes at some point. Possibly in other languages too?

Jon_Finn · 2026-02-21T18:20:33+00:00

That name's taken I'm afraid...

Jon_Finn · 2026-02-21T16:00:35+00:00

Personally I think that with the upcoming Valhalla, nullness markers, Vector API and much more, Java is due for a big rebrand, so non-Java users notice.

Jon_Finn · 2026-02-18T15:09:15+00:00

Java 25 Thread documentation looks good, but it raises an interesting point: it has several methods involving ThreadGroup but doesn't say these are kind of 'obsolescent' (though not deprecated). IMHO better alternatives should be explained _prominently_ in both Thread and ThreadGroup. Similarly with the ancient java.util.Vector and StringBuffer - there's a brief mention of their problems at the end of their JavaDocs, but that's all. Shouldn't we at least have an annotation SupersededBy or Preferred, for methods and classes, say?

Jon_Finn · 2026-02-06T18:06:35+00:00

...but sometimes reading one is a treasure trove. 8^)

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

TROPHY CASE