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".
--Joe
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