RFR(m): 8145468 deprecations for java.lang

[Brian Goetz]

Or, better, don’t do that in ASM, and instead use .equals()?  

> On Apr 14, 2016, at 9:21 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Stuart,
> you are not the first one to try to change the integers defined in org.objectweb.asm.Opcodes, those values are compared by ref (not by value) inside ASM.
> You're patch will change the behavior of any Interpreters that also use some Integers created by Integer.valueOf() because valueOf may cache the Integer references. 
> 
> I will add a comment in the ASM trunk for avoid such refactoring in the future.
> 
> reagrds,
> Rémi
> 
> 
> ----- Mail original -----
>> De: "Stuart Marks" <stuart.marks at oracle.com>
>> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoyé: Jeudi 14 Avril 2016 03:50:14
>> Objet: RFR(m): 8145468 deprecations for java.lang
>> 
>> Hi all,
>> 
>> Please review this first round of deprecation changes for the java.lang
>> package.
>> This changeset includes the following:
>> 
>>  - a set of APIs being newly deprecated
>>  - a set of already-deprecated APIs that are "upgraded" to forRemoval=true
>>  - addition of the "since" element to all deprecations
>>  - cleanup of some of the warnings caused by new deprecations
>> 
>> Webrevs:
>> 
>>   http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.jdk/
>> 
>>   http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.langtools/
>> 
>>   http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.top/
>> 
>> The newly deprecated APIs include all of the constructors for the boxed
>> primitives. We don't intend to remove these yet, so they don't declare a
>> value
>> for the forRemoval element, implying the default value of false. The
>> constructors being deprecated are as follows:
>> 
>>   Boolean(boolean)
>>   Boolean(String)
>>   Byte(byte)
>>   Byte(String)
>>   Character(char)
>>   Double(double)
>>   Double(String)
>>   Float(float)
>>   Float(double)
>>   Float(String)
>>   Integer(int)
>>   Integer(String)
>>   Long(long)
>>   Long(String)
>>   Short(short)
>>   Short(String)
>> 
>> The methods being deprecated with forRemoval=true are listed below. All of
>> these
>> methods have already been deprecated. They are all ill-defined, or they don't
>> work, or they don't do anything useful.
>> 
>>   Runtime.getLocalizedInputStream(InputStream)
>>   Runtime.getLocalizedOutputStream(OutputStream)
>>   Runtime.runFinalizersOnExit(boolean)
>>   SecurityManager.checkAwtEventQueueAccess()
>>   SecurityManager.checkMemberAccess(Class<?>, int)
>>   SecurityManager.checkSystemClipboardAccess()
>>   SecurityManager.checkTopLevelWindow(Object)
>>   System.runFinalizersOnExit(boolean)
>>   Thread.countStackFrames()
>>   Thread.destroy()
>>   Thread.stop(Throwable)
>> 
>> Most of the files in the changeset are cleanups. Some of them are simply the
>> addition of the "since" element to the @Deprecated annotation, to indicate
>> the
>> version in which the API became deprecated.
>> 
>> The rest of the changes are cleanup of warnings that were created by the
>> deprecation of the boxed primitive constructors. There are a total of a
>> couple
>> hundred such uses sprinkled around the JDK. I've taken care of a portion of
>> them, with the exception of the java.desktop module, which alone has over 100
>> uses of boxed primitive constructors. I've disabled deprecation warnings for
>> the
>> java.desktop module for the time being; these uses can be cleaned up later.
>> I've
>> filed JDK-8154213 to cover this cleanup task.
>> 
>> For the warnings cleanups I did, I mostly did conversions of the form:
>> 
>>    new Double(dval)
>> 
>> to
>> 
>>    Double.valueOf(dval)
>> 
>> This is a very safe transformation. It changes the behavior only in the cases
>> where the code relies on getting a new instance of the box object instead of
>> one
>> that might come out of a cache. I didn't see any such code (and I should hope
>> there's no such code in the JDK!).
>> 
>> I applied autoboxing only sparingly, in the cases where it was an obviously
>> safe
>> thing to do, or where nearby code already uses autoboxing. Autoboxing
>> actually
>> generates a call to the appropriate valueOf() method, so the bytecode would
>> be
>> the same in most cases. The only difference is clutter in the source code. On
>> the other hand, there's some risk in converting to autoboxing, as the
>> implicitly
>> autoboxed type might end up different from an explicit call to valueOf().
>> This
>> isn't always obvious, so that's why I mostly avoided autoboxing.
>> 
>> Thanks,
>> 
>> s'marks
>> 
>>