RFR(m): 8145468 deprecations for java.lang

[Stephen Colebourne]

FWIW. I would prefer to see these constructors removed and the JLS
simplified at the earliest possible date. Not using these classes as
the value types for primitives in Valhalla would be very confusing.
Stephen


On 15 April 2016 at 08:49, Remi Forax <forax at univ-mlv.fr> wrote:
> Hi Heinz,
> i think we should go nuclear on this, deprecate the Integer constructor *and* remove the line in the spec that says that Integer.valueOf (and Byte, Short, Character, Long) uses a cache and admit that the Java spec should not have a premature optimization carved in it.
>
> About your example about EA, do you agree that if the set is declared as a Set<int>, there is no such issue anymore ?
>
> Rémi
>
> ----- Mail original -----
>> De: "Dr Heinz M. Kabutz" <heinz at javaspecialists.eu>
>> À: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoyé: Vendredi 15 Avril 2016 07:26:03
>> Objet: Re: RFR(m): 8145468 deprecations for java.lang
>>
>> 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.
>>
>> Heinz
>>
>> Heinz
>>