RFR(m): 8145468 deprecations for java.lang

[Stuart Marks]

On 4/14/16 10:26 PM, Dr Heinz M. Kabutz wrote:
> Vladimir Ivanov wrote:
>> 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.
>>
> 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.

Vladimir, Heinz,

Thanks for thinking about this. I'd love to see EA improved. It might be 
possible to do so without any changes to the specs... but we can also change the 
specs, within limits, if it will make it easier to do EA or other optimizations.

I'll note that in Integer.valueOf(), the cache range is from -128 to 127 
inclusive. The lower bound is a constant, but the upper bound is set by a 
property and thus isn't a constant! This is set by -XX:AutoBoxCacheMax and also 
by -XX:+AggressiveOpts I think. Would turning the upper bound into a compile 
time constant make things any easier? It's not clear to me the ability to set 
the cache range is of any use.

In any case the main goal here is to pave the way toward value objects, and to 
get their full benefit, code needs to migrate away from constructs that expose 
the identity of the boxed values. This applies to all of the boxed primitives.

s'marks