A disclaimer or two for Optional

Joe Bowbeer joe.bowbeer at gmail.com
Tue Oct 22 20:23:03 PDT 2013

Does the paragraph below from Rose's blog list everything that shouldn't be
done to an Optional?

A value-safe expression may not be the subject of a value-unsafe operation.
>  In particular, it cannot be synchronized on, nor can it be compared with
> the “==” operator, not even with a null or with another value-safe type.

Comparing an Optional with null would be pretty funny.  For other potential
value types, such as Boolean and Integer, comparing with null is,
unfortunately, a somewhat common idiom: null means "not assigned".


On Sun, Oct 20, 2013 at 10:40 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 10/20/2013 07:01 PM, Joe Bowbeer wrote:
>> The Integer.valueOf definition is useful to Java programmers developing
>> for contained devices, and library writers trying to eek out performance.
>> (These Java programmers are not idiots. They are us.)
> Sorry but we are all idiots when we start to think about performance
> because we focus only on the current data, the current program, the current
> VM, the current OS, the current hardware and all of these things change
> faster than our own vision of the world.
> Anyway, that's not the issue here. The real issue is that this part of the
> Java spec is overspecified as Josh said.
>  It creates a safe zone for equals, much like the specification that
>> string constants are ==.
> again String constantification is not free, VMs use a global shared
> dictionary.
>  Changing Integer values is a Java 10 order of change.
> yes, maybe, start to warn now, and change in 10, or just give up with
> Integers has Brian said.
>  I'm fine with carving a spot for Optional evolution, but it is going to
>> be challenging to document in a way that is not misunderstood.
> yes, it's challenging.
> Rémi
>  On Oct 20, 2013 9:47 AM, "Remi Forax" <forax at univ-mlv.fr <mailto:
>> forax at univ-mlv.fr>> wrote:
>>     On 10/20/2013 06:09 PM, Brian Goetz wrote:
>>         Right, which is why Integer is likely too far polluted to be
>>         rescued. But, wouldn't it have been better if we could enforce
>>         that no one depended on it in the first place?  Wouldn't it be
>>         a shame for Optional to join it in the "hopelessly polluted by
>>         identity" department?
>>     JLS 5.1.7 is what is what is usually called a premature optimization.
>>     IMO the only sane choice is to just remove the wording about
>>     caching and performance and pretend that it has never existed.
>>     Rémi
>>         On 10/20/2013 12:08 PM, Joe Bowbeer wrote:
>>             Remi: Integer.valueOf is defined to return singletons for
>>             a range of
>>             values near zero, and new instances in other cases. Java
>>             programmers
>>             understand what this means, and their code sometimes
>>             depends on it.
>>             On Oct 20, 2013 5:52 AM, "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/20/2013 03:32 AM, Joshua Bloch wrote:
>>                     Brian,
>>                     On Sat, Oct 19, 2013 at 3:17 PM, Brian Goetz
>>                     <brian.goetz at oracle.com
>>             <mailto:brian.goetz at oracle.com**>
>>             <mailto:brian.goetz at oracle.com
>>             <mailto:brian.goetz at oracle.com**>>
>>                     <mailto:brian.goetz at oracle.com
>>             <mailto:brian.goetz at oracle.com**>
>>                     <mailto: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 anTy
>>                          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.
>>                     That's great because, frankly, Java's type system
>>             is way too
>>                     simple.  I'm glad you guys are investigating ways
>>             to make it
>>                     more complex, and to provide additional ways to do
>>             things that
>>                     people are already doing. This will keep Java
>>             programmers on
>>                     their toes, which, frankly, is just what they need.
>>                     Josh
>>                 Hi Josh,
>>                 It's a consequence of the introduction of
>>             auto-boxing/unboxing.
>>                 When you call Integer.valueOf() you explicitly say
>>             that you don't
>>                 care about the identity of the returned object, only
>>             the wrapped
>>                 value is important.
>>                 As you know, you can not predict the result of
>>             Integer.valueOf(x) ==
>>                 Integer.valueOf(x), which means that == on Integer is
>>             meaningless.
>>                 Currently, the code that try to remove boxing in the
>>             VM is full of
>>                 special cases because the semantics of boxing is not
>>             the same for
>>                 each wrappers (and is also partially specified in each
>>                 Wrapper.valueOf). Recognizing that value types already
>>             exist in
>>                 Java, and give them a proper documented semantics* is
>>             in my opinion
>>                 a good idea.
>>                 cheers,
>>                 Rémi
>>                 *by example, what is an array of value types is an
>>             interesting question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131022/b0d94a11/attachment-0001.html 

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