JDK-8180205 : Umbrella: potential JDK core library API deprecations
  • Type: Enhancement
  • Component: core-libs
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2017-05-11
  • Updated: 2025-06-20
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
tbdUnresolved
Related Reports
Relates :  
JDK-8065614 - JEP 277: Enhanced Deprecation
Relates :  
JDK-8160203 - Umbrella: enhancements to the deprecation mechanism
Sub Tasks
JDK-7029334 :  
Deprecate clone() and Cloneable - Closed
JDK-8145469 :  
deprecate legacy collections: Vector, Hashtable, etc. - Open
JDK-8154799 :  
deprecate Timer and TimerTask - Open
JDK-8160606 :  
(opt) deprecate Optional.get() - Open
JDK-8164898 :  
deprecate java.util.Date, java.util.Calendar, and related classes - Open
JDK-8180206 :  
deprecate Piped{Input,Output}Stream and Piped{Reader,Writer} - Open
JDK-8180207 :  
deprecate StringTokenizer and StreamTokenizer - Open
JDK-8180209 :  
un-deprecate AWT Component.hide and show - Closed
JDK-8180210 :  
(prefs) deprecate the java.prefs module - Open
JDK-8181098 :  
Deprecate java.io.File or some of its individual methods - Open
JDK-8192991 :  
Deprecate ThreadGroup - Open
Description
This is an umbrella bug to contain subtasks that cover deprecation of various core libraries APIs.
Comments
Most of the subtasks that remain open would add ordinary deprecation (forRemoval=false) to these classes and APIs, not terminal deprecation (forRemoval=true). After an initial round of deprecations, we've mostly held off adding ordinary deprecations to obsolescent classes that we intend to leave in the platform for compatibility purposes. The reason is that it adds warnings to builds, and people who like to keep their code warnings-free are forced to add suppressions; this doesn't add much value. We should revisit this if we change or enhance the warnings policy in javac.
20-06-2025