RFR(m): 8145468 deprecations for java.lang
brian.goetz at oracle.com
Thu Apr 14 17:13:42 UTC 2016
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.
> ----- 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
>> 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
>> 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
>> for the forRemoval element, implying the default value of false. The
>> constructors being deprecated are as follows:
>> The methods being deprecated with forRemoval=true are listed below. All of
>> methods have already been deprecated. They are all ill-defined, or they don't
>> work, or they don't do anything useful.
>> SecurityManager.checkMemberAccess(Class<?>, int)
>> 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
>> 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
>> 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
>> java.desktop module for the time being; these uses can be cleaned up later.
>> filed JDK-8154213 to cover this cleanup task.
>> For the warnings cleanups I did, I mostly did conversions of the form:
>> new Double(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
>> 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
>> thing to do, or where nearby code already uses autoboxing. Autoboxing
>> generates a call to the appropriate valueOf() method, so the bytecode would
>> 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
>> autoboxed type might end up different from an explicit call to valueOf().
>> isn't always obvious, so that's why I mostly avoided autoboxing.
More information about the core-libs-dev