A clarification: Rust only makes this guarantee for certain types[1] which you would expect to be represented by a simple pointer under the hood (e.g., Box<U>, &T, function pointers) and for other types which can never be all 0.

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.)

[1]: https://doc.rust-lang.org/std/option/#representation

> Kinda like Rust guarantees that Option<T> has the same size as T (aka free like in free beer).

That is not correct. Trivial counterexample:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

prints

    4
    8

i.e. Option<T> is 4 bytes larger than plain T

Sure, I meant:

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.

UPDATE: Or, better per your example: struct T {i: i32} takes the same size as i32: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Primitive classes are being worked on in Project Valhalla.

I think this statement has been true since about 2014.

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.

Alternatively: This is such a (potentially) big change, it's important to get right. I'd be disappointed if an inadequately-baked solution gets rushed in.

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.

That makes sense, given the fact that they made "new Foo()" pretty lightweight anyway (for CPU, not for RAM).

Some features take a long time when you have millions of users and billions of loc. Goetz recently did a State of Valhalla interview here: https://www.youtube.com/watch?v=x1_DBqJrykM

It's mostly implemented in a branch. You can download a version of Java that can do this today. There's more work to do before it can be merged though, and will probably ship in incremental pieces.

> 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.

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.

The semantics of primitive types should make it possible for the JVM to apply this optimization automatically. Maybe controlled via an annotation. But no clue whether it's on the roadmap.

> 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.

Valhalla is being actively worked on, I'm not sure what you are implying here.

Because they don't want to do a Python move, and those compiled JARs from 2000 should keep working as much as possible on a Valhala aware JVM.

I haven't been following it incredibly closely, but I have checked in from time to time. It's a hard problem, but there's a lot of real progress (https://github.com/openjdk/valhalla-docs/blob/main/site/desi...).

I'd wager that it will ship by the next LTS, in 2024.

2023 (hopefully)! They're proposing moving LTS to 2 years instead of 3.

You get null for free.

Can’t tell if this meant to be a statement of fact, opinion or sarcasm. Over the course of 20 years have I have probably spent days of time tracking down NPEs in code being developed and after the fact in production releases. The amount of extra code and time spent to determine if variable is null certainly isn’t free.

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.

I really like the Kotlin approach, where they just embraced null being a fact of life on the JVM/JS and instead integrated nullability into the type-system [1]. C# and Typescript do something similar.

So then you get the best of both world, the safety of Optional without the boxing overhead.

[1] https://kotlinlang.org/docs/null-safety.html

This really sounds like the way to go, although of course it is too late for Java. Optional feels awkward, and there's no more safety than we already have since the JVM null-checks anyway.

   if( arg.isPresent() ) ...

vs

   if( arg != null ) ...

How is this better?

The main advantage is that Optional is inconvenient and forces you to consider the null case. It's easy to forget that values can be null and assume they're not, e.g. auto-unboxing

    Long getSomeValue();

    int max = Math.max(0, obj.getSomeValue());

The Optional value forces you to type some text basically acknowledging that the value can be null.

    Optional<Long> getSomeValue();
    ... obj.getSomeValue().get());

I'm not saying Optional is a great solution. It's essentially a notification that a value is nullable.

Luckily it's not too late. A C#/Kotlin approach could be introduced and would not interfere with existing Optional.

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.

It's impossible for Option<T> to be the same size as T. Option is a tagged enum, where will the tag go?

Looks like it's only true for pointer types which cannot be null (so they can reuse null as the None tag)

https://doc.rust-lang.org/std/option/