> The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here.

I agree. The stewardship of Java seems rather lacking - particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start.

Does Java even have any value or mindshare at Oracle nowadays? The company seems to be a datacentre/compute business at this point, with appendiges for its legacy activities and a vast overhang of debt.

I sometimes wonder if the only parts of Oracle that are still profitable are the Legal and Lawnmower divisions.

so your complaint is about the blogger, not the Java language?

also, null markers are coming too: https://openjdk.org/jeps/8303099

Its just that they have to deliver things incrementally. This PR that introduces value classes/objects is already 200k lines long.

They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that.

That said, we've been gnawing on this limb for a while...

Nullable is just a different loadout state in Railway Orientated Programming. So, no reason to put different flavours of state into the language directly, when its a solved thing since (checks slides) 2012. There is just rails - going to A or going to B, depending on the trains loadout.

If you have language-wars about a concept going in and out of existence, that is a hint that there is demand and the language does not properly handle the demand or when it handles it, it creates mental overload.

> Value

> Errorstates

  > Null

  > IoExceptions

  > WeirdOsStatesNeededToHandleUpstairs

As the pythons said: Get on with it!

> it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly.

I think you've missed what this is referring to. It isn't about null safety (which is orthogonal) but about having reference/value projections analogous to Integer/int.

What the Valhalla team ended up doing is, instead of having two projections for each type, one with identity and one without, value types never have identity and so Integer and int are synonymous, and the memory layout is determined automatically based on context and optimisation decisions. This is why the semantics of == for the primitive wrappers (like Integer) were changed, as they now don't depend on whether the "reference projection" or the "value projection" is used.

> There is no reason to reduce the optional(!) safety guarantees you can offer with the excuse of "too mentally taxing".

This is not what happened here.

This is mainly for performance and memory layouts, it would not have improved safety guarantees of java.

I mean, I appreciate the huge engineering and design challenges here, but C# had non-null value types in 2002. It had generic value types in 2005 and it gained not-null “types with identity” in 2019 and no-one has batted an eyelid. (Indeed the type system support for value types still includes stuff Java isn’t even considering yet.)

Saying the mental model is too hard is basically saying your userbase is stupid. This stuff is not tricky.

> a single type would have two projections: a value variant (flat, never null, behaving like a primitive) and a reference variant (a box that allows null). Across various iterations this was written as Point.val/Point.ref, and later they experimented with the Point! and Point? syntax.

This seems heavier? Having two representations and manually having to refer to .val or .ref?

You can argue that the extra flexibility lets you write safer (non-nullable) code but naively it seems more complex at the language level.

Java made several mistakes. It also made some questionable (yet often defensible) decisions. It's understandable. Type erasure was one I believe was a mistake. It's talked about in the article. Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics. Notably, C# looked at that and said "nope". Type erasure is also hurting Valhalla here and the issue of value classes in generics is the second phase so is being pushed far into the future.

But a huge mistake (IMHO) was not having nullability part of the type system. You can still do this with type erasure.

Anyway, I read your comment as "nullability isn't complex" (paraphrased) but that's not the author's point. What's complex is having a value class and a regular class of every class and you don't necessary know which one you're dealing with at the language level.

C++ is a great example of this. You can create an object ont he stack or the heap and that's really what we're talking about with that proposal. And that's a nightmare. Combined with pointers it meant you never knew if you could free something or not and that ownership had to be passed around with vague comments like "// retains ownership".

Anyway, the whole article is a great tale of how difficult it is to retrofit things later and how difficult it can be to fix mistakes later (eg java.util.Date).

> very little faith that Java can be steered in a sensible direction here.

What? It’s been getting better with each release. Valhalla brings features that address key problems, and they didn’t rush to it either.

Like yeah, every field is final but omg non-null is a bridge to far! Wtf?

Yes, in this respect Java is 100% doomed. They've made a terrible decision and they're sticking with it for the sake of "consistency".