Value types, encapsulation, and uninitialized values

[Brian Goetz]

I wish I could say it was a "choice" at this point; at this point it is 
merely an argument that (IMO) sticking the developer with 100% of the 
responsibility for avoiding the default value is a bad balance, and will 
be a repeated source of sharp edges.  But assuming everyone agreed on 
that, there is still quite a range of options here, and comparing the 
costs are pretty subtle.  So its quite possible that what seems most 
natural for the programming model might not be where we land, depending 
on what the cost tradeoffs are.

For example, some classes (e.g., Optional, LocalDate) can easily find a 
single field which is never nonzero for valid values; this reduces the 
cost of checking for uninitialized values significantly, at a small cost 
to the programmer.  (And if all bits are used, they can explicitly add a 
byte/boolean to serve this purpose.)  But for others, the unused values 
are not as cleanly identified (imagine a 16-bit float class, wanting to 
steal one of the NaN bit patterns (exponent=1111, significand != 0) to 
indicate "uninitialized".  That's harder.  Harder still would be asking 
the JVM to make an upcall to a Java `isNull()` method from the middle of 
the acmp_null bytecode...

So, while the negotiation between the user model and the JVM plays out, 
suffice it to say that we're aware that having methods invoked on 
"uninitialized" values does not feel very "codes like a class", and 
we'll do our best to come up with a balanced solution.


On 10/16/2018 3:31 AM, Stephen Colebourne wrote:
> Agreed. The choice seems sound. What I was driving at with "much
> better" is a performance model where nullable values get closer to 80%
> of the benefits than only 50%. Not that it can be distilled to a
> percentage of course...
>
> I also agree that a nullable value might need one more bit (which
> might align to a lot more), but I want to ensure that those nullable
> values that can arrange things such that their natural all-zero bits
> is not valid (like LocalDate or Money) can avoid that extra bit.