A disclaimer or two for Optional
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