Movatterモバイル変換


[0]ホーム

URL:


Country
Contact Sales
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 offorRemoval=true andforRemoval=false. TheforRemoval=true text indicates that a deprecated API might be removed from the next major release. TheforRemoval=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 theJDK 9 Migration Guide for descriptions of specific compatibility issues.

TheKinds 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 inThe 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 theCompatibility & 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

SeeJDK-8074165

core-libs
 Deprecate sun.misc.Unsafe.defineClass

The methodsun.misc.Unsafe.defineClass is deprecated for removal. Use the methodjava.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 givenLookup's lookup class.

SeeJDK-8181442

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

ClassesBoolean,Byte,Short,Character,Integer,Long,Float, andDouble 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 thevalueOf 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 theJava Language Specification, section 5.1.7, "Boxing Conversion." For example, givenList<Integer> intList, the code to add anInteger 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 theList.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 theInteger 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 theInteger 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 thevalueOf 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 thevalueOf static factory method.

Using autoboxing or thevalueOf 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 ofBoolean has static fields for the two cached instances, namelyBoolean.FALSE andBoolean.TRUE.

With the exception ofCharacter, the box classes also have constructors that take aString argument. These parse and convert the string value and return a new instance of the box class. AvalueOf overload taking aString is the equivalent static factory method for this constructor. Usually it's preferable to call one of theparse methods (Integer.parseInt,Double.parseDouble, etc.) which convert the string and return primitive values instead of boxed instances.

SeeJDK-8065614

core-libs/java.lang
 Deprecate Object.finalize

Thejava.lang.Object.finalize method has been deprecated. The finalization mechanism is inherently problematic and can lead to performance issues, deadlocks, and hangs. Thejava.lang.ref.Cleaner andjava.lang.ref.PhantomReference provide more flexible and efficient ways to release resources when an object becomes unreachable. For further information, please see thejava.lang.Object.finalize method specification.

SeeJDK-8165641

core-svc/tools
 Deprecate policytool

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

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

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

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

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

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

SeeJDK-8170388

hotspot/gc
 UseAutoGCSelectPolicy has been deprecated

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

SeeJDK-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

SeeJDK-8162744

hotspot/gc
 AutoGCSelectPauseMillis has been deprecated

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

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

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

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

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

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

SeeJDK-8161506

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

Thecom.sun.jarsigner package is now deprecated. This includes theContentSigner class, theContentSignerParameters interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options.

SeeJDK-8076535

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

The classes and interfaces in thejava.security.acl andjavax.security.cert packages have been superseded by replacements for a long time and are deprecated in JDK 9. Two methodsjavax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain() andjavax.net.ssl.SSLSession.getPeerCertificateChain() are also deprecated since they return thejavax.security.cert.X509Certificate type.

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

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

SeeJDK-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, seeJEP 221. For more details on the new Doclet API, see thejdk.javadoc module.

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

SeeJDK-8168826



[8]ページ先頭

©2009-2025 Movatter.jp