This section describes the deprecated APIs, features, and options that have been identified as deprecated in this release and are subject to removal from future versions of Java SE and the JDK. They should be used with that possibility in mind.
Other sources of information about the APIs, features, and options deprecated in Java SE 9 and JDK 9 include:
What’s New in JDK 9 - Identifies deprecated APIs, features, and options as well as provides links to the documents where they are described in detail.
Deprecated API page (API specification) - Identifies all deprecated APIs including those deprecated in Java SE 9.
JSR 379: Java SE 9: Annex 1 - Documents changes to the specification made between Java SE 8 and Java SE 9 that include the identification of deprecated APIs and features not described here.
You should be aware of the contents in those documents as well as the items described in this release notes page.
The descriptions of deprecated APIs might include references to the deprecation warnings of forRemoval=true
and forRemoval=false
. The forRemoval=true
text indicates that a deprecated API might be removed from the next major release. The forRemoval=false
text indicates that a deprecated API is not expected to be removed from the next major release but might be removed in some later release.
Note: JEP 277: Enhanced Deprecation provides a detailed description of JDK 9's updated deprecation policy. You should be aware of the updated policy described in this document.
The descriptions below also identify potential compatibility issues that you might encounter when migrating to JDK 9. See the JDK 9 Migration Guide for descriptions of specific compatibility issues.
The Kinds of Compatibility page on the OpenJDK wiki identifies three types of potential compatibility issues for Java programs used in these descriptions:
Source: Source compatibility concerns translating Java source code into class files.
Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link without error.
Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.
See the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for additional information about compatibility as it relates to the JDK 9.
The AppletViewer tool was deprecated as a part of "JEP C161: Deprecate the Java Plug-in", and its use isn't recommended,
For more information about AppletViewer, see: appletviewer
The method sun.misc.Unsafe.defineClass
is deprecated for removal. Use the method java.lang.invoke.MethodHandles.Lookup.defineClass
to define a class to the same class loader and in the same runtime package and protection domain of a given Lookup
's lookup class.
Classes Boolean
, Byte
, Short
, Character
, Integer
, Long
, Float
, and Double
are "box" classes that correspond to primitive types. The constructors of these classes have been deprecated.
Given a value of the corresponding primitive type, it is generally unnecessary to construct new instances of these box classes. The recommended alternatives to construction are autoboxing or the valueOf
static factory methods. In most cases, autoboxing will work, so an expression whose type is a primitive can be used in locations where a box class is required. This is covered in the Java Language Specification, section 5.1.7, "Boxing Conversion." For example, given List<Integer> intList
, the code to add an Integer
might be as follows:
intList.add(new Integer(347));
This can be replaced with:
intList.add(347);
Autoboxing should not be used in places where it might affect overload resolution. For example, there are two overloads of the List.remove
method:
List.remove(int i) // removes the element at index i
List.remove(Object obj) // removes an element equal to obj
The code to remove the Integer
value 347 might be as follows:
intList.remove(new Integer(347));
If this code is changed in an attempt to use autoboxing:
intList.remove(347);
This will not remove the Integer
value 347, but instead it will resolve to the other overloaded method, and it will attempt to remove the element at index 347.
Autoboxing cannot be used in such cases. Instead, code should be changed to use the valueOf
static factory method:
intList.remove(Integer.valueOf(347));
Autoboxing is preferable from a readability standpoint, but a safer transformation is to replace calls to the box constructors with calls to the valueOf
static factory method.
Using autoboxing or the valueOf
method reduces memory footprint compared to the constructors, as the integral box types will generally cache and reuse instances corresponding to small values. The special case of Boolean
has static fields for the two cached instances, namely Boolean.FALSE
and Boolean.TRUE
.
With the exception of Character
, the box classes also have constructors that take a String
argument. These parse and convert the string value and return a new instance of the box class. A valueOf
overload taking a String
is the equivalent static factory method for this constructor. Usually it's preferable to call one of the parse
methods (Integer.parseInt
, Double.parseDouble
, etc.) which convert the string and return primitive values instead of boxed instances.
The java.lang.Object.finalize
method has been deprecated. The finalization mechanism is inherently problematic and can lead to performance issues, deadlocks, and hangs. The java.lang.ref.Cleaner
and java.lang.ref.PhantomReference
provide more flexible and efficient ways to release resources when an object becomes unreachable. For further information, please see the java.lang.Object.finalize
method specification.
The policytool
security tool is deprecated in JDK 9. It will be removed in a future release.
The ability to double-jar (jarjar) a set of class files in Java deployment technologies has been deprecated. The following warning will be issued if a jarjar file is downloaded:
"WARNING: A jarjar file has been loaded. Jarjar files are deprecated and will be removed in a future Java release. This application may not function properly in the future. Jarjar file URL: {URL}"
Java Applet and WebStart functionality, including the Applet API, The Java plug-in, the Java Applet Viewer, JNLP and Java Web Start including the javaws tool are all deprecated in JDK 9 and will be removed in a future release.
The '-makeall' argument of the Java Packager's command line interface has been deprecated. Use of '-makeall' will result in a warning. In lieu of the '-makeall' command, independent commands should be issued to perform compilation, createjar, and deploy, steps.
The com.sun.java.browser.plugin2.DOM, and sun.plugin.dom.DOMObject APIs have been deprecated and will be removed in a future release of Java. Applications can use netscape.javascript.JSObject to manipulate the DOM.
The flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses
has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags -XX:+ExplicitGCInvokesConcurrent
and -XX:+ClassUnloadingWithConcurrentMark
.
This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option.
The CMS garbage collector was deprecated in JDK 9. For more information, see -XX:+UseConcMarkSweepGC
This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option.
The VM Option "-Xprof" is deprecated in JDK 9 and will be removed in a future release. The option provides some profiling data for code being executed to standard output. Better data can be gathered with other tools such as Java Flight Recorder and therefore "-Xprof" will no longer be available in a future release.
The HostServices.getWebContext method is deprecated in JDK 9 and is marked as forRemoval=true indicating that it will be removed in a future version of the JDK. Applets are deprecated in JDK 9, and this method is only used when running an FX application as an Applet in a browser.
Support for VP6 video encoding format and FXM/FLV container are deprecated in JavaFX Media and it will be removed in a future release. Users encouraged to use H.264/AVC1 in MP4 container or HTTP Live Streaming instead.
The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details.
The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and these methods should no longer be used and are subject to removal in a future version of Java SE.
The com.sun.jarsigner
package is now deprecated. This includes the ContentSigner
class, the ContentSignerParameters
interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options.
The classes and interfaces in the java.security.acl
and javax.security.cert
packages have been superseded by replacements for a long time and are deprecated in JDK 9. Two methods javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()
and javax.net.ssl.SSLSession.getPeerCertificateChain()
are also deprecated since they return the javax.security.cert.X509Certificate
type.
The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements.
The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead.
The standard doclet is the doclet in the JDK that produces the default HTML-formatted API output. The version that was available in previous releases (com.sun.tools.doclets.standard.Standard) has been replaced by a new version (jdk.javadoc.doclet.Standard). The old version is now deprecated and is subject to removal in a future version of Java SE. For more details, see JEP 221. For more details on the new Doclet API, see the jdk.javadoc module.
The java launcher's data model switches, -d32 and -d64, were used primarily on Solaris platforms. With the removal of 32-bit JDK/JRE on Solaris in JDK8, these options are now obsolete and will be removed in a future release, causing the launcher to fail with an invalid option.