A disclaimer or two for Optional

[Joe Bowbeer]

Doug,

I think I understand what you're saying to mean that Optional instances may
be reused, which is what factory methods often do.

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.

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.



On Sat, Oct 19, 2013 at 12:54 PM, Joe Bowbeer <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> 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);
>>     }
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131019/d8667d6c/attachment.html