JDK-8154213 : clean up uses of boxed primitive constructors in the java.desktop module
  • Type: Bug
  • Component: client-libs
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-04-14
  • Updated: 2020-12-01
  • Resolved: 2016-04-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b117Fixed
Related Reports
Relates :  
JDK-8257512 - Remove use of deprecated primitive constructors in JavaFX
Relates :  
JDK-8145468 - update java.lang APIs with new deprecations
Description
JDK-8145468 will deprecate the boxed primitive constructors. There are currently over 100 uses of these constructors in the java.desktop module; these will generate warnings at compile time. The changeset for JDK-8145468 will temporarily disable deprecation warnings for java.desktop.

This bug covers cleanup of these warnings. As part of this cleanup, the deprecation warnings should be re-enabled.

For the most part, changing a call to a constructor can straightforwardly be replaced by a call to the corresponding valueOf() method. For example,

    new Double(dval)

can be replaced with

    Double.valueOf(dval)

It's possible to use 'dval' itself in some contexts, and rely on autoboxing, but this can be a bit dangerous. I only recommend converting to autoboxing if it's clear from context that relying on it is safe.
Comments
Good analysis. Using valueOf() is definitely safer than autoboxing. Consider: /* 1 */ Object o1 = new Long(123); /* 2 */ Object o2 = Long.valueOf(123); /* 3 */ Object o3 = 123; Converting line 1 to line 2 will still result in the Long object, however line 3, using autoboxing, will result in an Integer object. Also make sure to watch out for autoboxing within a ternary expression. In the webrev for JDK-8145468: http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.1.jdk/ See the changes to src/java.base/share/classes/java/text/DecimalFormat.java at line 2096. It's pretty easy to mess this up, especially in this code, which expects the boxes to be of a particular type. And yes, there is no direct replacement for new Float(double). You have to do Float.valueOf((float)dval). That's what the new Float(double) constructor does internally anyway -- that is, it just casts double to float.
15-04-2016
I probably will prefer valueOf () since there is at least one place from even a quick look where the API receives "Object" so autoboxing would not know what to do, and you can end up calling the wrong method if you aren't making sure of what all the similar signatures are. Before I can do this I need to wait for JDK-8145468 so that I can make sure I got them all by re-enabling the warnings. One (minor) thing I note is that we use "new Float(double)" in at least one place (SpinnerModel.java) and there is no Float.valueOf(double). We will need to explicitly cast.
15-04-2016
Please evaluate it
14-04-2016