A disclaimer or two for Optional

Brian Goetz brian.goetz at oracle.com
Sat Oct 19 19:33:35 PDT 2013


The Flatland analogy is apt!

Doug's wording was carefully chosen to be consistent and sensible in the 
present reality, but the motivation did ride into town on a flux 
capacitor.  Its a delicate dance between claiming to predict the future 
and ignoring a very real and entirely forseeable risk.

But you can see the point.  IF we're going to have values, then Optional 
should certainly be one; all the type safety with non of the runtime 
overhead of boxes, identity, object headers, or indirection.  What a 
shame it would be if we couldn't make that change when we got there, 
just because someone used it as a lock.

On 10/19/2013 10:23 PM, Joe Bowbeer wrote:
> Thanks for the background.  You can see the problem though.  This
> discussion is like a chapter from Flatland.  In this case a value-type
> visitor from the future is trying to explain its existence to the
> current denizens of Java land.  If Optional is not like something else
> that exists now, then statements about what not to do will cause
> confusion.  (Java programmers will interpret the statements in terms of
> what they know, like I did, and probably get it wrong.)  You need to
> give this new thing a name (like @ValueType) to make it clear that this
> is something new and unfamiliar.
>
>
> On Sat, Oct 19, 2013 at 3:17 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     OK, here's some of the background you may be missing.
>
>     "A future version of Java" will almost certainly have support for
>     "value types", "user-defined primitives", "identity-less
>     aggregates", "structs", or whatever you would like to call them.
>       Without making promises or projections or even going into any
>     details, this is high on the priority list, and some nontrivial
>     analysis has already been done on what it might look like and what
>     the migration compatibility concerns would be.
>
>     Doug's (completely correct) point about Optional is: morally, it
>     *should* be a value type, and it would be a massive (and entirely
>     predictable) shame if we could not, in a migration-compatible way,
>     evolve it to be one in the future, when such a thing is possible to
>     express in Java.
>
>     The set of things that would break under such a migration is quite
>     small: basically, "don't use it as a lock."  Which, as Doug points
>     out, is stupid anyway.  It would be a shame if we lost the benefit
>     of unboxing Optional just because we wanted to be compatible with
>     some doofus using it as a lock object.
>
>     This language just might be enough to deter such usage enough that
>     we could justify the incidental breakage in the future for the sake
>     of the greater good.
>
>
>
>
>     On 10/19/2013 5:21 PM, Joe Bowbeer wrote:
>
>         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
>         <mailto:forax at univ-mlv.fr>
>         <mailto:forax at univ-mlv.fr <mailto: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>
>
>
>         <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>
>                  <mailto:forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>>
>         <mailto:forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>
>
>                  <mailto: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>>
>                  <mailto:joe.bowbeer at gmail.com
>         <mailto:joe.bowbeer at gmail.com> <mailto:joe.bowbeer at gmail.com
>         <mailto:joe.bowbeer at gmail.com>>__>
>                           <mailto:joe.bowbeer at gmail.com
>         <mailto:joe.bowbeer at gmail.com>
>                  <mailto:joe.bowbeer at gmail.com
>         <mailto:joe.bowbeer at gmail.com>> <mailto: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>>
>                  <mailto:dl at cs.oswego.edu <mailto:dl at cs.oswego.edu>
>         <mailto:dl at cs.oswego.edu <mailto:dl at cs.oswego.edu>>>
>                               <mailto:dl at cs.oswego.edu
>         <mailto:dl at cs.oswego.edu> <mailto:dl at cs.oswego.edu
>         <mailto:dl at cs.oswego.edu>>
>                  <mailto: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);
>                                       }
>
>
>
>
>
>
>


More information about the lambda-libs-spec-experts mailing list