3 ms·
The more likely scenario is that Optional will get made into a value type.
by kaba0 3y ago
The more likely scenario is that Optional will get made into a value type.
- imtringued 3y agoShowing 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 agoAh, 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 agoOptional *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.