<p dir="ltr">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.)</p>
<p dir="ltr">It creates a safe zone for equals, much like the specification that string constants are ==.</p>
<p dir="ltr">Changing Integer values is a Java 10 order of change.</p>
<p dir="ltr">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.</p>
<div class="gmail_quote">On Oct 20, 2013 9:47 AM, "Remi Forax" <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/20/2013 06:09 PM, Brian Goetz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</blockquote>
<br>
JLS 5.1.7 is what is what is usually called a premature optimization.<br>
IMO the only sane choice is to just remove the wording about caching and performance and pretend that it has never existed.<br>
<br>
Rémi<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 10/20/2013 12:08 PM, Joe Bowbeer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Remi: Integer.valueOf is defined to return singletons for a range of<br>
values near zero, and new instances in other cases. Java programmers<br>
understand what this means, and their code sometimes depends on it.<br>
<br>
On Oct 20, 2013 5:52 AM, "Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a><br>
<mailto:<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>>> wrote:<br>
<br>
On 10/20/2013 03:32 AM, Joshua Bloch wrote:<br>
<br>
Brian,<br>
<br>
<br>
On Sat, Oct 19, 2013 at 3:17 PM, Brian Goetz<br>
<<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a> <mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a><u></u>><br>
<mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a><br>
<mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a><u></u>>__>> wrote:<br>
<br>
OK, here's some of the background you may be missing.<br>
<br>
"A future version of Java" will almost certainly have<br>
support for<br>
"value types", "user-defined primitives", "identity-less<br>
aggregates", "structs", or whatever you would like to call<br>
them.<br>
Without making promises or projections or even going into anTy<br>
details, this is high on the priority list, and some nontrivial<br>
analysis has already been done on what it might look like<br>
and what<br>
the migration compatibility concerns would be.<br>
<br>
<br>
That's great because, frankly, Java's type system is way too<br>
simple. I'm glad you guys are investigating ways to make it<br>
more complex, and to provide additional ways to do things that<br>
people are already doing. This will keep Java programmers on<br>
their toes, which, frankly, is just what they need.<br>
<br>
Josh<br>
<br>
<br>
Hi Josh,<br>
<br>
It's a consequence of the introduction of auto-boxing/unboxing.<br>
When you call Integer.valueOf() you explicitly say that you don't<br>
care about the identity of the returned object, only the wrapped<br>
value is important.<br>
As you know, you can not predict the result of Integer.valueOf(x) ==<br>
Integer.valueOf(x), which means that == on Integer is meaningless.<br>
<br>
Currently, the code that try to remove boxing in the VM is full of<br>
special cases because the semantics of boxing is not the same for<br>
each wrappers (and is also partially specified in each<br>
Wrapper.valueOf). Recognizing that value types already exist in<br>
Java, and give them a proper documented semantics* is in my opinion<br>
a good idea.<br>
<br>
cheers,<br>
Rémi<br>
*by example, what is an array of value types is an interesting question.<br>
<br>
</blockquote></blockquote>
<br>
</blockquote></div>