A disclaimer or two for Optional

[Joe Bowbeer]

Thanks, I'm aware of the blog post, but this post is not post of a Java
programmer's education our experience, so some explicit treatment will be
need if Optional is going to be breaking new ground.
On Oct 19, 2013 2:11 PM, "Remi Forax" <forax at univ-mlv.fr> wrote:

> On 10/19/2013 11:01 PM, Joe Bowbeer wrote:
>
>> 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.
>>
>
> There is a nice blog post from John Rose about value type.
> https://blogs.oracle.com/**jrose/entry/value_types_in_**the_vm<https://blogs.oracle.com/jrose/entry/value_types_in_the_vm>
>
> Rémi
>
>
>>
>> On Sat, Oct 19, 2013 at 1:38 PM, Remi Forax <forax at univ-mlv.fr <mailto:
>> 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>
>>         <mailto: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>
>>             <mailto: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/6d9e7812/attachment.html