A disclaimer or two for Optional
Ali Ebrahimi
ali.ebrahimi1781 at gmail.com
Sat Oct 19 16:23:17 PDT 2013
Or even annotate with @ValueType and javac warn for undesirable usages
(lock object, ...).
On Sun, Oct 20, 2013 at 1:47 AM, 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);
>> }
>>
>>
>>
>>
>>
>>
>>
More information about the lambda-libs-spec-observers
mailing list