Java 10: These APIs are as good as gone

© Shutterstock / Tik
This shouldn’t come as a surprise since some APIs have been deprecated for ages and have been superseded by newer APIs. While some APIs are as good as gone, others are eligible for removal in a future release but they haven’t been removed from this Specification.
According to the Java 10 Specification draft, a few changes have been made since the Public Review, mostly related to APIs.
APIs removed from Java 10
Following the conventions established by the Enhanced Deprecation feature, various APIs were annotated with
forRemoval=true
in the Java SE 9 Platform Specification (JSR 379), “APIs Proposed for Removal”, indicating that they were eligible for removal in a future release.
These APIs have been deprecated since at least Java SE 1.2 and have been superseded by newer APIs. Therefore, they are removed from this Specification.
Fields
Methods
- java.lang.Runtime.getLocalizedInputStream(java.io.InputStream)
- java.lang.Runtime.getLocalizedOutputStream(java.io.OutputStream)
- java.lang.SecurityManager.classDepth(java.lang.String)
- java.lang.SecurityManager.classLoaderDepth()
- java.lang.SecurityManager.currentClassLoader()
- java.lang.SecurityManager.currentLoadedClass()
- java.lang.SecurityManager.getInCheck()
- java.lang.SecurityManager.inClass(java.lang.String)
- java.lang.SecurityManager.inClassLoader()
Dead APIs walking: Eligible for removal in a future release
These modules were proposed for removal by the Java SE 9 Platform Specification, “APIs Proposed for Removal”. Even though they are not removed from this Specification, they are eligible for removal in a future release.
- java.activation
- java.corba
- java.se.ee (aggregator)
- java.transaction
- java.xml.bind
- java.xml.ws
- java.xml.ws.annotation
You can find out more about the modules mentioned above and their APIs in JEP 320. Since standalone versions of the APIs and their implementations are now available, you are advised to migrate to standalone versions right now.
Speaking of Java EE modules, they have been annotated as deprecated for removal in Java 9, which already indicated the intent to remove them in a future release [That “future release” could be Java 11]. Read more about the removal of Java EE modules here.
These APIs are (still) eligible for removal in a future release.
Classes
Methods
- java.lang.Runtime.runFinalizersOnExit
- java.lang.Runtime.traceInstructions
- java.lang.Runtime.traceMethodCalls
- java.lang.SecurityManager.checkAwtEventQueueAccess
- java.lang.SecurityManager.checkMemberAccess
- java.lang.SecurityManager.checkSystemClipboardAccess
- java.lang.SecurityManager.checkTopLevelWindow
- java.lang.System.runFinalizersOnExit
- java.lang.Thread.countStackFrames
- java.lang.Thread.destroy
- java.lang.Thread.stop
SEE ALSO: First JDK 10 Release Candidate is here
Last but not least, these APIs are annotated as @Deprecated
with forRemoval=true
in the current Specification. Therefore, they are eligible for removal in a future release of the Platform.
Packages
Interfaces
- java.security.acl.Acl
- java.security.acl.AclEntry
- java.security.acl.Group
- java.security.acl.Owner
- java.security.acl.Permission
Classes
- java.security.Certificate
- java.security.Identity
- java.security.IdentityScope
- java.security.Signer
- javax.security.auth.Policy
Exceptions
- java.security.acl.AclNotFoundException
- java.security.acl.LastOwnerException
- java.security.acl.NotOwnerException
Fields
Methods
- java.io.FileInputStream.finalize
- java.io.FileOutputStream.finalize
- java.util.zip.Deflater.finalize
- java.util.zip.Inflater.finalize
- java.util.zip.ZipFile.finalize
Read more about deprecations in the Deprecated API list of the API Specification.
While you’re at it, make sure to read Dustin Marx’s blog post in which he looks at some of the APIs that appear likely to be removed in JDK 10 and others that have been proposed to be deprecated in JDK 10.
So… what’s the replacement? The docs are actually pretty terrible.
For example, “java.security.acl.Group” says, “It has been replaced by java.security.Policy and related classes since 1.2.” But a Policy is a collection of Permission, not a collection of users, and I don’t see any class around Policy which looks like it represents a group.