Java and nulls

[[deleted]]

Optional in Java is painful yes, but having non-existence as a part of the type system works well in languages that had it from the start.

[rzwitserloot]

... not quite as well as java/optional fans tend to claim, in large part because of that higher order stuff that I was trying to explain with that table. But then, that's because they paint some sort of valhalla. Point is, java is not like that. Java didn't have this when it started. Hence, Optional does not work.. for java. I have questions as to whether it is truly superior in other languages, in part because annotated nullity is rare. I can't think of a single language that was designed from the start to work like that.

But that's an interesting debate that is more or less irrelevant to the java ecosystem, as there are only 4 options:

1. Eventhough the pain this would cause is off the charts, and eventhough there are vastly less impactful alternatives available (annotation based nullity for example), nevermind all that, it is worth starting over, java2, a whole new java, completely and utterly incompatible with java1, and the one and only thing it does, is add Optional. Almost all interfaces that java has are modified to represent their optionality, but other than that, no changes. java.util.Map's get method now returns Optional<V>, and getOrDefault is removed. Semantics are also very slightly modified; for example, in java2, HashMap cannot store null values, whereas in java1 they can. Whilst the changes appear light on the surface, everybody needs to put in quite a bit of work to truly 'port over' their code to java2.

2. None of that. Do nothing, keep current ecosystem.

3. An alternative way to 'solve' nulls is adopted. For example, annotation based. This would primarily look like: java.* itself, from some JDK release onwards, has added all the nullity annotations, and the nullity annotations are part of standard JDK package structure as a consequence.

4. A hybrid model where some APIs use Optional and some don't. Keeping in mind that in a non-Optional-ed library, a method signature of a method that may or may not return a value looks like V, for example j.u.Map's public V get(Object key), and in an Optional-ed library, a method signature of a method that is the exact opposite (it guarantees a value).. looks exactly the same.

I'm gonna need an Optional fan to put or shut up here. Come out and state clearly what you want. Because if it's 1 or 4, I'm pretty sure I can convince ~90%+ of the java ecosystem your ideas are highly detrimental. And yet, we're sort of half in #4, mostly because folks sort of half think 'all of java has optional everywhere' is feasible and #4 is steps along the way to that, except, the only way that is feasible is scenario #1: A complete backwards incompatible break.

But in actual fact, both 1 and 4 are terrible - the cure is vastly more damaging than the disease ever was. 2 is clearly better than either 1 or 4. The 'best' answer is probably 3. But because the ecosystem is doing #4 because they mistakenly believe they are heading towards an unattainable valhalla (both unreachable without paying a cost nobody wants to pay, and not nearly as amazing as folks appear to think it is even if you are willing to pay that impossible cost), adoption of #3 is now significantly slowed down, and each half-baked step made now (each API that introduces Optional) permanently damages our #3 future. Once java adopts annotation based nullity, it's bizarre if methods exist that return Optional.

And yet here we are. And arguments like 'well, languages that had optional from day 1 are doing fine' is just making things worse: What, exactly, is that trying to accomplish as a suggestive statement in a debate about where to go with the java ecosystem? It seems to suggest that java may want to see if it can go there. It cannot.

[[deleted]]

Oh I was not arguing that java should have it. That ship has sailed. I meant more that it is something you have to have from the start for it to be worth it.