----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Rémi Forax" <fo...@univ-mlv.fr> > Cc: "Stuart Marks" <stuart.ma...@oracle.com>, "core-libs-dev" > <core-libs-dev@openjdk.java.net> > Envoyé: Jeudi 14 Avril 2016 21:06:28 > Objet: Re: RFR(m): 8145468 deprecations for java.lang > > Sure, there is some inconvenience. But neither of these reasons seem to rise > to the level of "good reasons not to fix it". >
These Integers are not integers, they are objects that implement a kind of extensible state pattern (like using an interface and an enum in a more modern Java style) that happen to use the integer value has a debug info (the value are the same as the value defined for the StackMapTable see the JVM spec 4.7.4). The right fix should be to use real objects instead of java.lang.Integers here but there is no way to fix that without breaking the backward compatibility because those public constants are typed Integer. > Depending on the identity of boxes is problematic and will surely get worse > in the future. Best to get clean now! If java.lang.Integer is retrofitted to be a value type in the future, sure it's an issue, in that case, we will have to re-consider that in the future, but i will not break the backward compatibility of ASM just because in the future java.lang.Integer may be a value type. That's said i fully agree that the constructor of java.lang.Integer should be deprecated, new code should not use java.lang.Integer the way ASM currently uses it. > > Sent from my iPhone Rémi > > > On Apr 14, 2016, at 2:17 PM, Rémi Forax <fo...@univ-mlv.fr> wrote: > > > > The Analyzer/Interpreter API is public so using equals instead of == will > > likely summon some strange bugs. > > > > It will also have an impact in term of performance because currently there > > is no virtual call in the part of the algo that does the analysis. > > > > cheers, > > Rémi > > > > Le 14 avril 2016 19:13:42 CEST, Brian Goetz <brian.go...@oracle.com> a > > écrit : > >> Or, better, don’t do that in ASM, and instead use .equals()? > >> > >>> On Apr 14, 2016, at 9:21 AM, Remi Forax <fo...@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.ma...@oracle.com> > >>>> À: "core-libs-dev" <core-libs-dev@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 > > >
