We’re sorry. We could not find a match for your search.

We suggest you try the following to help find what you’re looking for:

  • Check the spelling of your keyword search.
  • Use synonyms for the keyword you typed, for example, try "application" instead of "software."
  • Start a new search.
Cloud Account Sign in to Cloud
Oracle Account
java

JDK 9 Release Notes - Deprecated APIs, Features, and Options

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.


Deprecated APIs, Features, and Options

client-libs/java.awt
 AppletViewer is deprecated

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

See JDK-8074165

core-libs
 Deprecate sun.misc.Unsafe.defineClass

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.

See JDK-8181442

core-libs/java.lang
 Deprecation of Boxed Primitive Constructors

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.

See JDK-8065614

core-libs/java.lang
 Deprecate Object.finalize

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.

See JDK-8165641

core-svc/tools
 Deprecate policytool

The policytool security tool is deprecated in JDK 9. It will be removed in a future release.

See JDK-8147400

deploy
 Ability to double-jar class files is deprecated

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}"

See JDK-8074157

deploy
 Java Deployment Technologies are deprecated and will be removed in a future release

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.

See JDK-8184998

deploy/packager
 Java Packager '-makeall' argument deprecated

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.

See JDK-8160835

deploy/plugin
 Deprecation of common DOM APIs

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.

See JDK-8074162

hotspot/gc
 Deprecate the flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses

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.

See JDK-8170388

hotspot/gc
 UseAutoGCSelectPolicy has been deprecated

This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option.

See JDK-8166461

hotspot/gc
 JEP C175: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector in Oracle builds

The CMS garbage collector was deprecated in JDK 9. For more information, see -XX:+UseConcMarkSweepGC

See JDK-8162744

hotspot/gc
 AutoGCSelectPauseMillis has been deprecated

This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option.

See JDK-8166461

hotspot/runtime
 Deprecate FlatProfiler

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.

See JDK-8176098

javafx/application-lifecycle
 Deprecate HostServices.getWebContext method with forRemoval=true

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.

See JDK-8156963

javafx/media
 VP6 video and FXM/FLV container are deprecated

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.

See JDK-8134330

security-libs/java.security
 Deprecate the java.security.acl API

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.

See JDK-8157847

security-libs/java.security
 Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true

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.

See JDK-8161506

security-libs/java.security
 Deprecate the com.sun.jarsigner package

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.

See JDK-8076535

security-libs/java.security
 Deprecate security APIs that have been superseded

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.

See JDK-8073430

security-libs/javax.net.ssl
 Deprecate the javax.security.cert API

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.

See JDK-8157712

security-libs/javax.net.ssl
 Deprecate methods that reference javax.security.cert APIs

The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead.

See JDK-8161898

tools/javadoc(tool)
 The old standard doclet is deprecated and will be removed in a future release

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.

See JDK-8177484

tools/launcher
 Options -d32 and -d64 are deprecated

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.

See JDK-8168826