3 ms·

How does making Optionals allocated on the stack (value types) prevent this? Or rather why do you need value types to accomplish this?

by savanu 6y ago

bluejekyll 6y ago
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 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.
- savanu 6y ago
  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?
  - bluejekyll 6y ago
    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.
- pgwhalen 6y ago
  > Looking at https://openjdk.java.net/jeps/401 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.
chrisseaton 6y ago
> 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!

How does making Optionals allocated on the stack (value types) prevent this? Or rather why do you need value types to accomplish this?

by savanu 6y ago

How does making Optionals allocated on the stack (value types) prevent this? Or rather why do you need value types to accomplish this?

bluejekyll 6y ago

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

savanu 6y ago
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?
- bluejekyll 6y ago
  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.
pgwhalen 6y ago
> Looking at https://openjdk.java.net/jeps/401 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.

chrisseaton 6y ago

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