Say you have:

    public void doSomething(Optional<String> foo) { ... }

You want `foo` to be `Optional.empty()` or `Optional.of("some string")`. The way things currently work, `foo` could also be `null`.

Kotlin's approach of making null act kind of like Optional is pretty nice, but I wish there was a strict option for interacting with Java types -- by default, all Java-native types (type names ending with !) can be null and are not null checked at compile time.

In our code base we just throw a `?:` after any type that shows up as Type! and handle it immediately. If you actually expect a null value you can also use `?: null`

How does making Optionals allocated on the stack (value types) prevent this?

Or rather why do you need value types to accomplish this?

Perhaps this example will make it more obvious:

    boolean truthy = false;
    truthy = null; // compilation failure, type mismatch

vs. the Boolean type

    Boolean truthy = new Boolean(false);
    truthy = null; // compiles just fine

The reason Boolean (and other boxed primitive types) exist is because it is an Object (a reference type) and that allows them to be used in things like collections that expect Objects and not primitive types.

Looking at https://openjdk.java.net/jeps/401 it's not totally clear to me at the moment how you can use ValueTypes (primitive keyword) in Collections. Might be that you'll need to take a reference to them with Type.ref (but I need to read 401 in more detail to understand that).

Hope that helps.

> Looking at https://openjdk.java.net/jeps/401 it's not totally clear to me at the moment how you can use ValueTypes (primitive keyword) in Collections.

JEP 401 won't cover it quite yet, note this from the "Non Goals" section:

> An important followup effort, not covered by these JEPs, will enhance the JVM to specialize generic classes and bytecode for different primitive value type layouts.

It wasn't until recently that I understood for myself just how large the surface area of the "value types" problem is - it will be delivered incrementally. JEP 401 and 402 are the first steps (if I were to guess they will show up as previews soon? maybe JDK 17 or 18?), but there is more to come.

So you are really looking for compiler checks for null? Kind of like kotlin?

var truthy = null; // Compile fails

var nullable? = null; // Compile passes

You don't need value types for this?

That's not exactly the same thing... It can also (again I don't know if this is part of the jep or not) be used to perform stack based destructors (finalize) and then Java could implement RAII. Reading the jep it discusses perhaps rejecting finalize as function on primitive objects, so this might not be in scope.

Additionally, the type is also lighter weight than an Object and should be stack allocated, so there are memory advantages to not having to use boxed types as well.

> How does making Optionals allocated on the stack (value types) prevent this?

Let's not confuse language specification issues with implementation issues. Both value and object types can be allocated on the stack. Both can be allocated on the heap. Both can not be allocated at all and can be scalar replaced. So this isn't the meaningful difference!

There's a big difference between the Optional containing null (useful) and the Optional itself being null (but why).

> Isn't it being null sometimes — the whole point?

No you have it backwards - the whole point is that Optional is never null. You use empty instead.