A disclaimer or two for Optional

[Joe Bowbeer]

As a Java programmer, "value-type class" doesn't mean anything to me.

Is Integer a value-type class?  If so, then Optional is not so odd.  ==
still implies equals(); it does not return an arbitrary result.

If Optional is not like anything else in Java (it's neither a primitive
value nor an Object?) then a much more explicit disclaimer is needed.


On Sat, Oct 19, 2013 at 1:38 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> 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);
>>             }
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131019/c53f5161/attachment-0001.html