JDK-4941777 : Deprecate Boolean constructor
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.4.2,6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2003-10-22
  • Updated: 2024-04-12
  • Resolved: 2016-04-15
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.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8145468 - update java.lang APIs with new deprecations
Relates :  
JDK-4302078 - Boolean should have a static factory valueOf(boolean)
Relates :  
JDK-6428760 - Need Annotation @Denigrated
Relates :  
JDK-4262398 - Avoid creating new Booleans for increased operational speed
Description
Name: tb29552			Date: 10/22/2003


A DESCRIPTION OF THE REQUEST :
We should encourage people to move from "new Boolean()" to Boolean.TRUE, Boolean.FALSE by deprecating the constructor and documented the aforementioned alternative methods.

JUSTIFICATION :
Using Boolean.TRUE, Boolean.FALSE leads to improved performance, reduced memory footprint. Many developers are unaware of this recent addition and continue to use the constructor. A deprecation should formalize this migration route.
(Review ID: 216908) 
======================================================================
Comments
The Boolean constructor is being deprecated as part of JDK-8145468.
15-04-2016
Maybe the Byte() constructor should also be deprecated, since all Byte values are cached.
03-10-2015
Dr. Deprecator should provide a diagnosis for this situation.
03-10-2015
EVALUATION Contribution-Forum:https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=12004&forumID=1463
15-03-2006
EVALUATION Due to the disruption deprecating an API can have, currently an API has to be "actively hazardous" to be deprecated, like Thread.stop. While the use this constructor is certainly ill-advised, it doesn't rise (or sink) to the standard of hazardousness to be deprecated in the JDK. In the future we may add a "denigration" facility to mark API elements that aren't quite so bad that they should be deprecated, but shouldn't be used in most cases. This constructor would be a good candidate for denigration.
15-11-2005
PUBLIC COMMENTS .
10-06-2004
EVALUATION A reasonable request; the JavaDoc already encourages use of the static factory. ###@###.### 2003-10-30
30-10-2003