Hacker News new | ask | show | jobs
by savanu 1901 days ago
How does making Optionals allocated on the stack (value types) prevent this?

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

2 comments

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!