A disclaimer or two for Optional

Remi Forax forax at univ-mlv.fr
Sun Oct 20 09:44:22 PDT 2013

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.


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

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