Introducing a ValObject as super or having the ACC_VALUE bit are two representation of the same thing for the VM. In both case, we need to load the class to know if it's a value type or not, and in Java, the class loading is delayed which works well for reference type but not well for value type, if you have class that has a field which is a value type, you need to know if the field is a value type or not to be able to flatten it. With your proposal, the VM doesn't know if a field contains a value type or not until it's too late. Or are you suggesting to have a shape shifting objects (Skrulls objects) ?
No. As you say, from the VM perspective, the two are equivalent, as long as RefObject and ValObject are loaded super-early (which of course they can be.) To know whether to flatten a field is an orthogonal question. We explored an ACC_FLATTENABLE bit, and in BUR we settled on "flatten Qs, don't flatten Ls" -- but we could change again. But that is completely separate from how the class is declared.
same issue here, you want to know if something is nullable or not when you verify the bytecode, but at that point the class may not be loaded so you don't know if the class implements Nullable or not.
Again, you're talking at a different layer. At the VM level, we still use L/Q to describe nullability of _instances_. Putting Nullable in the type system let's the _language_ apply it to _types_, as in a typ bound: <T extends Nullable>. Different things.
Currently, you can not do == on value types, i.e. point1 == point2 doesn't compile, if you want a unified equality, you have to use equals.
Right. And I'm saying, we can't sell that. Values should work like an int; you can compare ints with ==. I think the "Currently" story doesn't wash.
