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