RFR(m): 8145468 deprecations for java.lang

Dr Heinz M. Kabutz heinz at javaspecialists.eu
Fri Apr 15 05:26:03 UTC 2016

Vladimir Ivanov wrote:
>> 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.)
> I'd say it's a motivating example to improve EA implementation in C2, 
> but not to avoid deprecation of public constructors in primitive type 
> boxes. It shouldn't matter for C2 whether Integer.valueOf() or 
> Integer::<init> is used. If it does, it's a bug.
> Best regards,
> Vladimir Ivanov
To do that would probably require a change to the Java Language 
Specification to allow us to get rid of the IntegerCache.  Unfortunately 
it is defined to have a range of -128 to 127 at least in the cache, so 
this probably makes it really hard or impossible to optimize this with 
EA.  I always found it amusing that the killer application for EA, 
getting rid of autoboxed Integer objects, didn't really work :-)

Stuart, I'm not a great fan of @SuppressWarning() and would personally 
prefer the constructors for integer types to stay non-deprecated.  
Boolean's constructor is fine to deprecate, as are Double and Float.



More information about the core-libs-dev mailing list