A disclaimer or two for Optional
Brian Goetz
brian.goetz at oracle.com
Sat Oct 19 15:17:04 PDT 2013
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>> 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> <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>>__>>
> 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>>>> 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-observers
mailing list