JDK-8252180 : [JEP 390] Deprecate wrapper class constructors for removal
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-08-21
  • Updated: 2020-12-14
  • Resolved: 2020-12-08
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 16
16 masterFixed
Related Reports
Blocks :  
CSR :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8254271 :  
Description
The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal in anticipation of these classes becoming inline classes.

java.lang.Byte
java.lang.Short
java.lang.Integer
java.lang.Long
java.lang.Float
java.lang.Double
java.lang.Character
java.lang.Boolean

The existing documentation seems to sufficiently describe the alternatives for creating instances of these classes.
Comments
Changeset: 48d8650a Author: Dan Smith <dlsmith@openjdk.org> Date: 2020-12-08 23:04:01 +0000 URL: https://git.openjdk.java.net/jdk/commit/48d8650a
08-12-2020

I had thought it made sense to also add the "this is a value-based class" boilerplate with this issue, but in retrospect it makes more sense as part of JDK-8254047. I've adjusted the descriptions.
13-10-2020

Updating to add @ValueBased is a separate task 8252181 that does not require a csr.
09-10-2020

I think it's an important part of the "feature", so makes sense to deliver as one unit. Programmers will see new warnings about their use of 'new Integer(23)' in JDK N, and will be helped by knowing that these new warnings are part of one of the items on the "what's in this release" list.
06-10-2020

Strictly speaking, changing to deprecate for removal is not dependent on the Warnings JEP. Can this be pushed to JDK independently from the JEP being targeted? It would decouple one small dependency.
05-10-2020