No results found

Your search did not match any results.

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.”
  • Try one of the popular searches shown below.
  • Start a new search.
Trending Questions

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.

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

JDK-8074165 (not public)

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

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

JDK-8074157 (not public)

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 the 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.

JDK-8074162 (not public)

docs/release_notes
 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.

JDK-8184998 (not public)

hotspot/gc
 AutoGCSelectPauseMillis has been deprecated 
The -XX:+AutoGCSelectPauseMillis option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy 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

JDK-8162744 (not public)

hotspot/gc
 UseAutoGCSelectPolicy has been deprecated 
The -XX:+UseAutoGCSelectPolicy option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option.

See JDK-8166461

hotspot/gc
 Deprecate the flag -XXExplicitGCInvokesConcurrentAndUnloadsClasses 
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/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 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:

  • inCheck field 
  • getInCheck method
  • classDepth method
  • classLoaderDepth method
  • currentClassLoader method
  • currentLoadedClass method
  • inClass method
  • inClassLoader method

This field and these methods are subject to removal in a future version of Java SE and should no longer be used.

See JDK-8161506

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 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
 Deprecate policytool 
The policytool security tool is deprecated in JDK 9. It will be removed in a future release.

See JDK-8147400

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.

JDK-8168826 (not public)