A disclaimer or two for Optional

[Remi Forax]

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

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);
>                     }
>
>
>
>
>