A disclaimer or two for Optional

Brian Goetz brian.goetz at oracle.com
Sun Oct 20 09:59:14 PDT 2013

> The virtue of Optional, in my experience with the Guava variety, is that
> the compiler never lets you forget that you aren't dealing with a Foo,
> you're dealing with a (probably lightweight, possibly magical) potential
> container of a Foo.

Agreed.  But currently, its not lightweight or magical; its a full-blown 
object box (a 4x cost in memory for a 32-bit pointer, plus a loss of 
locality, plus more work for the GC).  And, the fact that it has 
identity is what keeps the VM from being able to work magic.  Which is 
really sad!  Since no one really needs or benefits from that identity.

Wouldn't it be *even better* if we enabled future JDKs to represent 
Optional as an embeddable pointer-sized scalar under the covers, rather 
than a full-blown object box, while retaining all the type-safety?  The 
only thing standing in the way is misuse of == and synchronized between 
now and (some future time).  The Flatland conversation that reminds us 
not to do stupid things with Optional (and similar types like DateTime) 
seems a small price to pay for this representation flexibility.

The question to be discussed here should be: exactly how hortatory the 
Flatland visitor should be permitted to be.

More information about the lambda-libs-spec-experts mailing list