RFR(m): 8145468 deprecations for java.lang

[Dr Heinz M. Kabutz]

Hi Stuart,

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 :)

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion since 2005
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz



Stuart Marks wrote:
> 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
>
>