A disclaimer or two for Optional
Joe Bowbeer
joe.bowbeer at gmail.com
Sat Oct 19 19:23:56 PDT 2013
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> 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>> 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>>> 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);
>> }
>>
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131019/10c94289/attachment-0001.html
More information about the lambda-libs-spec-experts
mailing list