4 削除されたAPI
この項では、JDK 11からJDK 19までの各リリースで削除されたJava SE APIについて詳しく説明します。
jdeprscan --release 19 -l --for-removal
を実行して、JDK 19で削除対象としてマークされているAPIのリストを取得します。
ノート:
jdeprscanツールは、JDK 9以降で使用可能です。以前のJDKバージョンから非推奨APIのリストを印刷する場合は、リリース番号を対応するリリース・バージョンに置き換えます。Java SE 18で削除されたAPI
メソッド
java.awt.color.ICC_Profile.finalize()
java.awt.image.ColorModel.finalize()
java.awt.image.IndexColorModel.finalize()
Java SE 17で削除されたAPI
パッケージ
java.rmi.activation ()
クラス
java.rmi.activation.Activatable ()
java.rmi.activation.ActivationDesc ()
java.rmi.activation.ActivationGroup ()
java.rmi.activation.ActivationGroup_Stub ()
java.rmi.activation.ActivationGroupDesc ()
java.rmi.activation.ActivationGroupID ()
java.rmi.activation.ActivationID ()
java.rmi.activation.ActivationInstantiator ()
java.rmi.activation.ActivationMonitor ()
java.rmi.activation.ActivationSystem ()
java.rmi.activation.Activator ()
Java SE 15で削除されたAPI
次のAPIはJava SE 15で削除されました。
フィールド
java.management.rmi.RMIConnectorServer.CREDENTIAL_TYPES
コンストラクタ
java.lang.invoke.ConstantBootstraps.<init>
java.lang.reflect.Modifier.<init>
Java SE 14で削除されたAPI
次のAPIはJava SE 14で削除されました。
java.security.acl
インタフェース
java.security.acl.Acl
java.security.acl.AclEntry
java.security.acl.Group
java.security.acl.Owner
java.security.acl.Permission
java.util.jar.Pack200.Packer
java.util.jar.Pack200.Unpacker
java.util.jar.Pack200
Java SE 13で削除されたAPI
java.lang.Runtime.traceInstructions(boolean)
java.lang.Runtime.traceMethodCalls(boolean)
Java SE 12で削除されたAPI
java.io.FileInputStream.finalize()
java.io.FileOutputStream.finalize()
java.util.zip.Deflater.finalize()
java.util.zip.Inflater.finalize()
java.util.zip.ZipFile.finalize()
JDK 11で削除されたAPI
JDK 11では、次のAPIが削除されました。これらのAPIの多くは以前のリリースで非推奨となり、新しいAPIで置き換えられています。
javax.security.auth.Policy
java.lang.Runtime.runFinalizersOnExit(boolean)
java.lang.SecurityManager.checkAwtEventQueueAccess()
java.lang.SecurityManager.checkMemberAccess(java.lang.Class,int)
java.lang.SecurityManager.checkSystemClipboardAccess()
java.lang.SecurityManager.checkTopLevelWindow(java.lang.Object)
java.lang.System.runFinalizersOnExit(boolean)
java.lang.Thread.destroy()
java.lang.Thread.stop(java.lang.Throwable)
JDK 10で削除されたAPI
JDK 10では、次の共通DOM APIが削除されました。
com.sun.java.browser.plugin2.DOM
sun.plugin.dom.DOMObject
JDK 9で削除されたAPI
JDK 10およびJDK 9リリースから削除された重要なAPIの一部を次に示します。
java.* APIの削除
Javaチームは下位互換性にコミットしています。アプリケーションがJDK 8で動作する場合、外部使用を意図したサポートされているAPIを使用しているかぎり、JDK 9以降のリリースでも動作します。
これには、次のものが含まれます:
- JCP標準、java.*、javax.*
- JDK固有のAPI、一部のcom.sun.*、一部のjdk.*
サポートされていたAPIがJDKから削除されることもありますが、必ず予告があります。コードが非推奨のAPIを使用しているかどうかを確認するには、静的分析ツールjdeprscanを実行します。
JDK 9で削除されたjava.* APIには、以前に非推奨となった、java.util.logging.LogManagerおよびjava.util.jar.Pack200パッケージの次のメソッドが含まれます。
java.util.logging.LogManager.addPropertyChangeListener
java.util.logging.LogManager.removePropertyChangeListener
java.util.jar.Pack200.Packer.addPropertyChangeListener
java.util.jar.Pack200.Packer.removePropertyChangeListener
java.util.jar.Pack200.Unpacker.addPropertyChangeListener
java.util.jar.Pack200.Unpacker.removePropertyChangeListener
sun.miscおよびsun.reflect APIからの削除および削除予定
java.* APIとは異なり、ほとんどすべてのsun.* APIはサポートされていないJDK内部APIであり、いつでもなくなる可能性があります。
一部のsun.* APIがJDK 9で削除されました。注意が必要な点として、sun.misc.BASE64Encoderおよびsun.misc.BASE64Decoderが削除されています。かわりに、JDK 8で追加された、サポートされているjava.util.Base64クラスを使用してください。
- sun.misc.Unsafe
このクラスの多くのメソッドの機能は変数ハンドルを使用することで実現できます。『JEP 193: Variable Handles』を参照してください。
- sun.reflect.Reflection::getCallerClass(int)
かわりにスタックウォーキングAPIを使用します。『JEP 259: Stack-Walking API』を参照してください。
java.awt.peerはアクセス不可
java.awt.peerおよびjava.awt.dnd.peerパッケージはJDK 9以降ではアクセスできません。このパッケージはjava.*ネームスペースにありますが、Java SE APIの一部であったことはありません。
これらのパッケージで定義されている型を参照するJava SE APIのすべてのメソッドが、JDK 9から削除されています。これらのパッケージで定義された型をこれまで受け付けたり返していたメソッドを呼び出すコードは、コンパイルや実行ができなくなりました。
- ピアがまだ設定されているかどうかを調べるには:
これをJDK 1.1 APIのComponent.isDisplayable()で置き換えてください。if (component.getPeer() != null) { .. }
public boolean isDisplayable() { return getPeer() != null;
- コンポーネントが軽量かどうかをテストするには:
これをJDK 1.2 APIのComponent.isLightweight()で置き換えてください。if (component.getPeer() instanceof LightweightPeer) ..
public boolean isLightweight() { return getPeer() instanceof LightweightPeer;
com.sun.image.codec.jpegパッケージの削除
非標準パッケージcom.sun.image.codec.jpegは削除されました。かわりにJava Image I/O APIを使用してください。
com.sun.image.codec.jpegパッケージは、JPEG形式のイメージ・ファイルのロードおよび保存を制御する非標準の方法としてJDK 1.2で追加されました。プラットフォーム仕様の一部となったことはありません。
JDK 1.4においてJava Image I/O APIが標準APIとして追加され、これはjavax.imageioパッケージにあります。これは選択されたイメージ形式のロードと保存を制御するための標準メカニズムを提供するもので、Java SE準拠のすべての実装においてJava Image I/O仕様に基づいてJPEGをサポートする必要があります。
コンパクト・プロファイルのツール・サポートの削除
JDK 9以降では、事前定義されたプロファイルに依存することなく、Javaランタイム・イメージ内のモジュールのサブセットに対してアプリケーションをビルドおよび実行できます。
SE 8で導入されたプロファイルは、Java SEプラットフォームAPIのサブセットを定義します。これにより、ストレージ容量が制限されているデバイス上でJavaランタイムの静的サイズを削減できます。JDK 8のツールでは、compact1
、compact2
およびcompact3
の3つのプロファイルをサポートしています。各プロファイルのAPI構成については、JDK 8のドキュメントの詳細なプロファイル構成およびAPIリファレンスに関する項を参照してください。
JDK 8では、javac
およびjava
コマンドを実行する際に-profile
オプションを使用してプロファイルを指定します。JDK 9以降では、-profile
オプションはjavac
において--release 8
オプションとの組合せでのみサポートされ、java
ではサポートされません。
JDK 9以降のリリースでは、コンパイルおよび実行時に使用されるモジュールを選択できます。新しい--limit-modules
オプションでモジュールを指定することで、コンパクト・プロファイル内にある同じAPIを取得できます。このオプションは、次の例に示すとおりjavac
コマンドとjava
コマンドの両方でサポートされています。
javac --limit-modules java.base,java.logging MyApp.java
java --limit-modules java.base,java.logging MyApp
-
compact1
プロファイル: java.base、java.logging、java.scripting -
compact2
プロファイル: java.base、java.logging、java.scripting、java.rmi、java.sql、java.xml -
compact3
プロファイル: java.basejava.logging、java.scripting、java.rmi、java.sql、java.xml、java.compiler、java.instrument、java.management、java.naming、java.prefs、java.security.jgss、java.security.sasl、java.sql.rowset、java.xml.crypto
jdeps
ツールを使用して、ソース・コードで使用されているJavaパッケージの静的分析を実行できます。これにより、アプリケーションを実行するのに必要なモジュールのセットがわかります。たとえばこれまでcompact3
プロファイルを使用していた場合、アプリケーションのビルド時にモジュールのセット全体を含める必要はないことが考えられます。Java Development Kitツール仕様のjdeps
に関する項を参照してください。
『JEP 200: The Modular JDK』を参照してください。
デフォルトでのCLDRロケール・データの使用
JDK 9以降ではUnicodeコンソーシアムの共通ロケール・データ・リポジトリ(CLDR)データがデフォルトのロケール・データとして有効化されており、特別に何かしなくても標準のロケール・データを使用できます。
JDK 8では、CLDRロケール・データはJREにバンドルされていましたが、デフォルトでは有効化されていませんでした。
日付、時間、数値書式といったロケール依存のサービスを使用するコードは、CLDRロケール・データにより異なる結果が生成されることがあります。System.out.printf()でさえロケールを認識します。
JDK 8互換の動作を有効にするには、システム・プロパティjava.locale.providers
の値で、CLDR
の前にCOMPAT
を設定します(たとえば、java.locale.providers=COMPAT,CLDR
)。
『Java Platform, Standard Edition国際化ガイド』のデフォルトで有効化されるCLDRロケール・データに関する項および『JEP 252: Use CLDR Locale Data by Default』を参照してください。