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