Are they going to introduce zero-cost structs?
Kinda like Rust guarantees that Option<T> has the same size as T (aka free like in free beer).
Kinda like Rust guarantees that Option<T> has the same size as T (aka free like in free beer).
Making this optimization for something like Option<u8> is, naturally, impossible.
(I assume you are aware of this and were implicitly referring to this optimization.)
That is not correct. Trivial counterexample:
https://play.rust-lang.org/?version=stable&mode=debug&editio...
prints
4
8
Rust guarantees to optimize the following types T such that Option<T> has the same size as T:
Box<U>
&U
&mut U
fn, extern "C" fn
num::NonZero*
ptr::NonNull<U>
#[repr(transparent)] struct around one of the types in this list.
Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to do.
This is such an important thing to add to Java, and it seems to be perpetually off the stove, not even on the back burner.
I'd wager that it will ship by the next LTS, in 2024.
Valhalla is being actively worked on, I'm not sure what you are implying here.
Another way of looking at it: This is fundamentally just a performance optimization. Java performance is already exceptional for most of Java's popular use cases (business processing). While valuable, I don't think this one feature is quite as important as you consider it.
As an aside, and not to say that Valhalla is not needed (I am looking forward to it very much, along with Loom), I’ve recently learned that for many use cases (not all) when you want gigabytes of struct arrays, a bunch of equal-sized primitive arrays, one per struct field, might work even better from memory requirement and cache locality perspective.
Optional at least states the variable may not be referencing anything and provides helpful methods to chain mapping and conditionals to more easily deal with null values.
So then you get the best of both world, the safety of Optional without the boxing overhead.
if( arg.isPresent() ) ... if( arg != null ) ...
Long getSomeValue();
int max = Math.max(0, obj.getSomeValue());
Optional<Long> getSomeValue();
... obj.getSomeValue().get());
The type system would need to be extended with a T? (nullable), T! (non-nullable), smart-casting on null-checks, and with some annotations or a flag to determine if T should be treated as T? or T! and whether you can call methods on it.
> How is this better?
It's not if you use Optional.get, but if you use .map, .orElse and the like the compiler can prevent you from getting NPEs instead of them being runtime.