A disclaimer or two for Optional

[Remi Forax]

On 10/19/2013 10:07 PM, Joe Bowbeer wrote:
> Doug,
>
> I think I understand what you're saying to mean that Optional 
> instances may be reused, which is what factory methods often do.

no, the idea is that the VM can always replace Optional by the wrapped 
value and re-wrap it if an Optional object is need.
Basically, Optional acts as a value type. In that case, the notion of 
identity is very fuzzy.

>
> If I understand, then I think it's confusing to say that == returns an 
> arbitrary result.  The meaning of == hasn't changed. For example, == 
> might still be employed in an implementation of Optional.equals().
>
> I'm not convinced that synchronized needs special treatment in the 
> javadoc either.  This should be clear to anyone who understands what 
> reuse means.

synchronized rely on the identity of the object.

>
> I think the important point to document is that reuse may be 
> arbitrary.  In particular, the statement that empty() may return 
> different instances -- this is surprising and needs to be documented.

Rémi

>
>
>
> On Sat, Oct 19, 2013 at 12:54 PM, Joe Bowbeer <joe.bowbeer at gmail.com 
> <mailto:joe.bowbeer at gmail.com>> wrote:
>
>     I don't understand why == means nothing, or why there is special
>     wording for == in the javadoc disclaimer.
>
>     Why does potential reuse mean that == says nothing?  Doesn't it
>     still mean they are the same instance?  That's not surprising.  It
>     is similar reuse to the valueOf factory methods, right?  And the
>     valueOf factory methods don't include a == disclaimer.  It comes
>     with the territory.
>
>     Or does opt1 == opt2 no longer imply that opt1.equals(opt2) ?
>
>     Or are Optional instances ephemeral?  Making it impossible for
>     applications to retain them.
>
>     If either of the above, I think a more explicit disclaimer is needed.
>
>     --Joe
>
>
>     On Sat, Oct 19, 2013 at 11:16 AM, Doug Lea <dl at cs.oswego.edu
>     <mailto:dl at cs.oswego.edu>> wrote:
>
>
>         This arose while contemplating some JDK9 possibilities...
>
>         Note that Optional is itself a value-like class, without
>         a public constructor, just factory methods.
>         The factory methods do not even guarantee to return unique
>         objects. For all that the spec does and should say,
>         every call to Optional.of could return the same Optional
>         object. (This would require a magical implementation,
>         but still not disallowed, and variants that sometimes
>         return the same one are very much possible.)
>
>         This means that there are no object-identity-related
>         guarantees for Optionals. "myOptional1 == myOptional2"
>         tells you nothing, and synchronized(myOptional) has
>         unpredictable effects -- it might block forever.
>
>         People might find this surprising, so we probably want to
>         add a sentence or two to the javadoc. How about the following.
>         (We could symmetrically say that the instance returned by
>         Optional.empty() need not be the  same each time, but that
>         might be overkill?)
>
>             /**
>              * Returns an {@code Optional} with the specified present
>         non-null value.
>         adding...
>         * The returned instance need not be unique. Thus the results of
>         * comparing two instances using @code{==}, or using one as the
>         * argument for a @code{synchronized} block are arbitrary and
>         should
>         * be avoided.
>              *
>              * @param <T> the class of the value
>              * @param value the value to be present, which must be
>         non-null
>              * @return an {@code Optional} with the value present
>              * @throws NullPointerException if value is null
>              */
>             public static <T> Optional<T> of(T value) {
>                 return new Optional<>(value);
>             }
>
>
>