RFR(m): 8145468 deprecations for java.lang

[Stuart Marks]

On 4/14/16 7:37 AM, Dr Heinz M. Kabutz wrote:
> in previous versions of Java, escape analysis did not seem to work particularly
> well with Integer.valueOf(int) values, since the objects of course could come
> from the Integer Cache.  Thus if the Integer object did not escape from your
> method, it could get eliminated entirely.  Not exactly sure what
> -XX:+EliminateAutoBox does, but my guess would be that there is some relation
> here.  So even though your changes look sensible, I'm just worried about
> deprecating the constructors taking a primitive as a parameter.  I haven't
> looked at this particular issue for a number of years, so it's entirely possible
> that it is a non-issue now :)

Hi Heinz,

I had a sidebar with Shipilev on this, and this is indeed still potentially an 
issue. Alexey's example was:

     set.contains(new Integer(i))      // 1

vs

     set.contains(Integer.valueOf(i))  // 2

EA is able to optimize away the allocation in line 1, but the additional 
complexity of dealing with the Integer cache in valueOf() defeats EA for line 2. 
(Autoboxing pretty much desugars to line 2.)

But there are a few things to note.

We're proposing to deprecate the boxed primitive constructors, but *not* for 
removal. This encourages people to migrate their code away from the 
constructors. There's no intent at the present time to remove the constructors.

I believe it's still preferable for general-purpose programming to use 
autoboxing or valueOf() in preference to the constructors.

For situations that are extremely performance critical, one can still use the 
constructor. The only difference is that this will generate a warning. I'd say 
that anyone who understands EA and who knows when calling the constructor will 
make a difference will also know how to add @SuppressWarnings in the right place.

Of course, these people will suffer when value types come along. :-)

I took a quick look through the valueOf() changes, and it doesn't look like any 
of these are really performance critical. Indeed, most of them create the boxed 
values for the purpose of storing into a field of reference type or into a 
collection, so an object will always have to be allocated on the heap. The EA 
issue doesn't apply to these cases; indeed, valueOf() is probably preferable for 
these cases, in order to benefit from the box caches.

This is a good issue to keep an eye out for, though. Thanks for mentioning it.

s'marks