A disclaimer or two for Optional

[Brian Goetz]

> Does the paragraph below from Rose's blog list everything that shouldn't
> be done to an Optional?
>
>     A value-safe expression may not be the subject of a value-unsafe
>     operation.  In particular, it cannot be synchronized on, nor can it
>     be compared with the “==” operator, not even with a null or with
>     another value-safe type.

Also: System.identityHashCode.  And assignment of null.

On the other hand, we are considering whether == and identityHashCode 
can be retrofitted to values by an automated componentwise/bitwise 
computation.  Which means that == is unwise but probably supportable. 
The real killer is synchronizing (and its friends, wait/notify.)

> Comparing an Optional with null would be pretty funny.  For other
> potential value types, such as Boolean and Integer, comparing with null
> is, unfortunately, a somewhat common idiom: null means "not assigned".

Right.  My take is that the existing primitive wrapper types are 
hopelessly polluted and must always mean "boxed primitives".  But, for 
new-in-8 classes (Optional, and the 310 date-time classes), there may be 
hope.