3 ms·

Showing an error on broken code will cost you backwards compatibility. The best you will get is a warning and the JVM will deoptimize Optional back to a regula

Showing an error on broken code will cost you backwards compatibility. The best you will get is a warning and the JVM will deoptimize Optional back to a regular object, because somewhere someone set an Optional to null somewhere in a library. It doesn't even have to be as obvious as Optional<String> o = null; Any cast to Optional can let a null pointer slip from an Object reference. List<Optional<String>> is allowed to contain null pointers and you are allowed to assign o = list.get(0) which generates an implicit cast. There is no good solution for this. Due to the way generics are implemented.

kaba0 3y ago
Ah, you mean the Optional itself being null. That’s not any bigger an issue than anything else being Optional. Also, value types might come combined with nullability — so you might have Optional<String>!, which can’t be null, and will efficiently be stored in-place.
DarkNova6 3y ago
Optional *is going to* be made a value type. However, unlike the binary choice of class/value type, project valhalla will provide a more granular approach, coming with incremental performance benefits and constraints. In the current spec draft, the type system boils down to 4 categories: - Fully mutable, polymorph classes - Immutable, monomorphic classes - Immutable, monomorphic classes + null-hostile - Immutable, monomorphic classes + null-hostile + multithreading-unsafe Another story for nullability is being investigated as well which would allow for full performance gain as well as full backwards compatibility.