A disclaimer or two for Optional

Remi Forax forax at univ-mlv.fr
Sun Oct 20 05:49:12 PDT 2013

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

*by example, what is an array of value types is an interesting question.

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