JDK 11では、次のAPIが削除されました。これらのAPIの多くは以前のリリースで非推奨となり、新しいAPIで置き換えられています。可能な代替方法の詳細は、JDK 11 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)

デフォルトでアクセスできないようになっている内部APIを使用する必要がある場合、--add-exportsコマンドライン・オプションを使用してカプセル化を解除できます。

--add-exports <source-module>/<package>=<target-module>(,<target-module>)*

--add-exportsオプションでは、ターゲット・モジュールがソース・モジュールを読み取る場合に、ターゲット・モジュール内のコードがソース・モジュールの名前付きパッケージ内のタイプにアクセスすることを許可します。

--add-exports java.management/sun.management=ALL-UNNAMED

--add-exports java.management/com.sun.jmx.remote.internal=ALL-UNNAMED

Add-Exports:java.management/sun.management

--add-exportsオプションは慎重に使用してください。これを使用すれば、ライブラリ・モジュールの内部APIに、またはJDKそのものの内部APIであってもアクセスできますが、これは自己責任になります。その内部APIが変更または削除されると、ライブラリやアプリケーションは失敗します。

JEP 261も参照してください。

非publicメンバーにアクセスするためにクラス・パスにあるコードにディープ・リフレクションの実行を許可する必要がある場合は、--add-opensランタイム・オプションを使用します。

一部のライブラリはディープ・リフレクションを実行する(つまりsetAccessible(true)となっている)ため、privateなメンバーを含め、すべてのメンバーにアクセスできます。このアクセス権は、javaコマンドラインで--add-opensオプションを使用して付与できます。このオプションの使用により警告メッセージが生成されることはありません。

--illegal-access=denyの場合、実行時にIllegalAccessExceptionまたはInaccessibleObjectExceptionメッセージが表示され、例外メッセージに表示される情報に基づいて引数に--add-opensランタイム・オプションを使用できます。

--add-opens module/package=target-module(,target-module)*

--add-opens java.management/sun.management=ALL-UNNAMED

<j2se version="10" java-vm-args="--add-opens=module/package=ALL-UNNAMED"  />

JDKのインストール後にファイル・システムを参照するとわかるとおり、ディレクトリ・レイアウトがJDK 9より前のリリースとは異なっています。

JDK 11以降

JDK 11以降にはJREイメージがありません。『Java Platform, Standard Editionインストレーション・ガイド』のJDKのインストール済ディレクトリの構造に関する項を参照してください。

JDK 9およびJDK 10

以前のリリースには2種類のランタイム・イメージがありました。1つはJREで、これはJava SE Platformの完全な実装、もう1つはJDKで、JRE全体がjre/ディレクトリに、開発ツールとライブラリとともに格納されていました。

JDK 9およびJDK 10では、JDKとJREは2種類のモジュラ・ランタイム・イメージで、次のディレクトリが含まれています。

• bin: バイナリ実行可能ファイルが格納されます。

• conf: 開発者、デプロイ実行者およびエンド・ユーザーによる編集を意図した、.properties、.policyおよびその他のファイルが格納されます。これらのファイルは以前はlibディレクトリまたはそのサブディレクトリにありました。

• lib: 動的にリンクされるライブラリおよびJDKの完全な内部実装が格納されます。

JDK 9およびJDK 10では、JDKとJREのダウンロードは引き続き分かれていますが、それぞれのディレクトリ構造は同じです。JDKイメージには、これまでJDKで提供されてきた追加のツールおよびライブラリが含まれています。jdk/とjre/のラッパー・ディレクトリはなく、(javaコマンドなどの)バイナリは複製されません。

『JEP 220: Modular Run-Time Images』を参照してください。

JDK 9以降のリリースでは1.2リリースから存在するクラス・ローダー階層が引き続き保持されます。ただし、モジュール・システムの実装のために次の変更が加えられました。

• アプリケーション・クラス・ローダーはURLClassLoaderのインスタンスではなくなり、内部クラスのインスタンスになります。これは、Java SEモジュールでもJDKモジュールでもないモジュールのクラスのデフォルト・ローダーです。

• 拡張クラス・ローダーという名前がプラットフォーム・クラス・ローダーという名前に変更されました。Java SEプラットフォームのすべてのクラスは、プラットフォーム・クラス・ローダーにより参照可能となることが保証されます。さらに、Java Community Processに基づいて標準化されているもののJava SEプラットフォームの一部ではないモジュールのクラスは、プラットフォーム・クラス・ローダーにより参照可能となることが保証されます。

  クラスがプラットフォーム・クラス・ローダーにより参照可能であるからというだけで、クラスが実際にプラットフォーム・クラス・ローダーにより定義されているということにはなりません。Java SEプラットフォームの一部のクラスはプラットフォーム・クラス・ローダーにより定義されているのに対し、あるものはブートストラップ・クラス・ローダーにより定義されています。アプリケーションは、どのクラス・ローダーでどのプラットフォーム・クラスが定義されているかに依存しないようにしてください。

  JDK 9で実装されたこの変更は、親クラス・ローダーとしてnull (つまり、ブートストラップ・クラス・ローダー)が設定されたクラス・ローダーを作成し、親からすべてのプラットフォーム・クラスが参照可能であることを前提とするコードに影響する可能性があります。そのようなコードは、親としてプラットフォーム・クラス・ローダーを使用するように変更する必要があります(ClassLoader.getPlatformClassLoaderを参照してください)。

  プラットフォーム・クラス・ローダーはURLClassLoaderのインスタンスではなく、内部クラスのインスタンスです。

• ブートストラップ・クラス・ローダーは引き続きJava仮想マシンに組み込まれており、ClassLoader APIにおいてnullで表されます。ここでは、java.baseといった、いくつかの重要なモジュールのクラスが定義されています。その結果、ここで定義されるクラスの数はJDK 8に比べてかなり少なくなり、-Xbootclasspath/aによりデプロイされるアプリケーションや親としてnullが設定されたクラス・ローダーを作成するアプリケーションは、前述のように変更が必要となる可能性があります。

以前にlib/rt.jar、lib/tools.jar、lib/dt.jarおよびその他の各種内部JARファイルに格納されていたクラスおよびリソースのファイルは、libディレクトリ内の実装固有のファイルにさらに効率的な形式で格納されています。

rt.jarおよび同様のファイルの削除により、次のような問題が発生します。

• JDK 9以降では、ClassLoader.getSystemResourceはJARファイルを指すURLは返しません(JARファイルがないため)。かわりに、ランタイム・イメージに格納されたモジュール、クラス、およびリソースの名前をそのイメージの内部構造や形式を公開することなく示す、jrt URLを返します。

  次に例を示します。

  ClassLoader.getSystemResource("java/lang/Class.class");

  JDK 8で実行すると、このメソッドは次の形式のJAR URLを返します。

  jar:file:/usr/local/jdk8/jre/lib/rt.jar!/java/lang/Class.class

  これにはラインタイム・イメージ内の実際のJARファイルの名前を示すファイルURLが含まれています。

  モジュラ・イメージにはJARファイルは含まれないため、この形式のURLは意味をなしません。JDK 9以降のリリースでは、このメソッドは次の値を戻します。

  jrt:/java.base/java/lang/Class.class

• java.security.CodeSource APIおよびセキュリティ・ポリシー・ファイルでは、特定の権限が付与されるコード・ベースの場所を示すのにURLを使用します。Java Platform, Standard Editionセキュリティ開発者ガイドのポリシー・ファイル構文に関する項を参照してください。特定の権限を必要とするランタイム・システムのコンポーネントは現在、conf/security/java.policyファイルにおいてファイルURLを使用して識別されます。

• 旧バージョンのIDEやその他の開発ツールでは、ランタイム・イメージに格納されたクラス・ファイルおよびリソース・ファイルを列挙する機能、およびrt.jarファイルおよび同様のファイルをオープンして読み取ることによりそのコンテンツを直接読み取る機能が必要となります。これはモジュラ・イメージでは不可能です。

JDK 8以前では、拡張メカニズムにより、クラス・パスで明示的に指定しなくても、ランタイム環境において拡張クラスを検出してロードすることが可能でした。JDK 9以降では、拡張クラスを使用する必要がある場合、JARファイルがクラス・パスにあることを確認してください。

JDK 9およびJDK 10では、java.ext.dirsシステム・プロパティが設定されている場合、またはlib/extディレクトリが存在する場合、javacコンパイラおよびjava起動ツールは終了します。プラットフォーム固有のディレクトリをシステム規模でさらに確認するには、-XX:+CheckEndorsedAndExtDirsコマンドライン・オプションを指定します。これにより、このディレクトリが存在していてかつ空でない場合に同じ終了動作が発生します。拡張クラス・ローダーはJDK 9以降のリリースでも引き続き保持され、プラットフォーム・クラス・ローダーとして指定されています(getPlatformClassLoaderを参照。)ただし、JDK 11でこのオプションは廃止され、使用すると警告が発行されます。

次のエラーは、システムが拡張メカニズムを使用するよう構成されていることを示しています。

<JAVA_HOME>/lib/ext exists, extensions mechanism no longer supported; Use -classpath instead.
.Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

java.ext.dirsシステム・プロパティが設定されている場合も同様のエラーが表示されます。

このエラーを修正するには、ext/ディレクトリまたはjava.ext.dirsシステム・プロパティを削除します。

『JEP 220: Modular Run-Time Images』を参照してください。

java.endorsed.dirsシステム・プロパティおよびlib/endorsedディレクトリは存在しなくなりました。このいずれかが検出された場合、javacコンパイラおよびjava起動ツールは終了します。

JDK 9以降では、アップグレード可能なモジュールを使用するか、またはJARファイルをクラス・パスに指定します。

このメカニズムは、アプリケーション・サーバーがJDKで使用されるコンポーネントをオーバーライドできるよう意図するものでした。更新されるパッケージはJARファイルに配置され、それがどこにあるかはシステム・プロパティjava.endorsed.dirsによりJavaランタイム環境側で判断できるようになっていました。このプロパティが指定されていない場合、デフォルトとして$JAVA_HOME/lib/endorsedが使用されるようになっていました。

JDK 8では、-XX:+CheckEndorsedAndExtDirsコマンドライン引数を使用して、システム上のどこかにあるそのようなディレクトリをチェックできます。

JDK 9以降のリリースでは、java.endorsed.dirsシステム・プロパティが設定されている場合、またはlib/endorsedディレクトリが存在する場合、javacコンパイラおよびjava起動ツールは終了します。

次のエラーは、システムが標準の推奨オーバーライド・メカニズムを使用するよう構成されていることを示しています。

<JAVA_HOME>/lib/endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

java.endorsed.dirsシステム・プロパティが設定されている場合も同様のエラーが表示されます。

このエラーを修正するには、lib/endorsedディレクトリを削除するか、またはjava.endorsed.dirsシステム・プロパティを設定解除します。

『JEP 220: Modular Run-Time Images』を参照してください。

Java 11インストーラは、次のWindowsレジストリ・キーをJDKのインストール時に作成します。

• "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK"

• "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\11"

2つのバージョンのJDKがインストールされている場合、2つの異なるWindowsレジストリ・キーが作成されます。たとえば、JDK 11.0.1をJDK 11とともにインストールする場合は、インストーラによって次のように別のWindowsレジストリ・キーが作成されます。

• "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK"

• "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\11.0.1"

JDK 9およびJDK 10リリースから削除された重要なAPIの一部を次に示します。

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

jdepsツールを使用して、ソース・コードで使用されているJavaパッケージの静的分析を実行できます。これにより、アプリケーションを実行するのに必要なモジュールのセットがわかります。たとえばこれまでcompact3プロファイルを使用していた場合、アプリケーションのビルド時にモジュールのセット全体を含める必要はないことが考えられます。Java Platform, Standard Editionツール・リファレンスのjdepsに関する項を参照してください。

『JEP 200: The Modular JDK』を参照してください。

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』を参照してください。

Nashornエンジン、jjsツール、およびjdk.scripting.nashornとjdk.scripting.nashorn.shellの各モジュールは、将来のリリースでの削除に備えてJDK 11で非推奨になりました。

Nashornエンジンまたはjjsツールを使用するアプリケーションを実行すると、警告メッセージが表示されます。スクリプトまたはツールでこれらの警告メッセージを想定していない場合は、この警告を抑制できます。

Nashorn Java APIを使用するアプリケーションを実行すると、警告: Nashornエンジンは将来のJDKリリースから削除される予定です。という警告メッセージが表示されます。この警告を抑制するには、nashorn.argsシステム・プロパティで--no-deprecation-warningオプションを指定します。たとえば、EvalScriptがNashorn Java APIを使用しているアプリケーションであると仮定します。警告を抑制するには、このアプリケーションを次のように実行します。

java -Dnashorn.args="--no-deprecation-warning" EvalScript

同様にjjsツールを実行すると、警告: jjsツールは将来のJDKリリースから削除される予定です。という警告が表示されます。この警告を抑制するには、--no-deprecation-warningオプションを指定します。

JDK 9以降では、起動時に起動されるJREとは異なるバージョンのJREを要求する機能は削除されています。

近年のアプリケーションは通常、Java Web Start (JNLP)、ネイティブOSパッケージ化システムまたはアクティブ・インストーラを使用してデプロイされます。これらのテクノロジは、必要なJREを必要に応じてダウンロードおよび更新する、必要となるJREを管理する独自の方法を備えています。そのため、起動ツールの起動時JREバージョン選択は非推奨となりました。

以前のリリースでは、アプリケーションの起動時にどのJREバージョン(またはバージョンの範囲)を使用するかを指定できました。バージョンの選択は、コマンドライン・オプションまたはアプリケーションのJARファイルのマニフェスト・エントリで可能でした。

『JEP 231: Remove Launch-Time JRE Version Selection』を参照してください。

JDK 9以降では、アプレットをシリアライズ・オブジェクトとしてデプロイする機能はサポートされていません。近年の圧縮およびJVMのパフォーマンスでは、このようにアプレットをデプロイするメリットはありません。

appletタグのobject属性およびobjectおよびjava objectアプレット・パラメータ・タグは、アプレットの起動時に無視されます。

アプレットをシリアライズするかわりに、通常の方法でデプロイしてください。

JNLP (Java Network Launch Protocol)が、不整合の解消、コードのメンテナンス性の向上、セキュリティの強化を目的として更新されました。

JNLPが次のように更新されました。

1. JNLPファイルにおける&のかわりの&の使用。

   JNLPファイル構文はXML仕様に準拠しており、すべてのJNLPファイルは標準のXMLパーサーによる解析が可能である必要があります。

   JNLPファイルでは複雑な比較を指定できます。これまでこれはアンパサンド(&)を使用して行われていましたが、これは標準XMLではサポートされていません。&を使用して複雑な比較を作成している場合、JNLPファイルで&に置き換えてください。&はすべてのバージョンのJNLPで互換性があります。

2. 数値バージョン要素タイプと非数値バージョン要素タイプの比較。

   これまで、intバージョンの要素とintとして解析できない他のバージョンの要素を比較する際は、両者をASCII値として辞書式に比較していました。

   JDK 9以降では、intとして解析できる要素が他の要素より短い文字列である場合、ASCII値に基づいて辞書式に比較する前に先行のゼロが埋め込まれます。これにより循環がないことが保証されます。

   バージョン比較とJNLPサーブレットの両方が使用される場合、数値のみを使用してバージョンを表す必要があります。

3. java (またはj2se)要素にネストされたリソースがあるコンポーネント拡張機能。

   これは仕様で許可されています。以前もサポートされていましたが、このサポートが仕様に反映されていませんでした。

4. FX XML拡張。

   JNLP仕様が強化され、type属性がapplication-desc要素に、そしてサブ要素paramがapplication-descに(すでにapplet-descにあるように)追加されました。

   JavaFXアプリケーションを指定する以前の方法も引き続きサポートされているため、これが既存のアプリケーションにおいて問題となることはありません。

JSR-056のJNLP仕様の更新に関する項を参照してください。

アプリケーションでこれまでJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesが必要だった場合、これをダウンロードまたはインストールする必要はなくなりました。これらはJDKに含まれており、デフォルトで有効化されています。

ご使用の国または使用状況によりさらに制限の厳しいポリシーが必要な場合は、制限付きJava暗号化ポリシー・ファイルを引き続き使用できます。

デフォルトで提供されているいずれかのポリシー・ファイルで満たされていない要件がある場合は、これらのポリシー・ファイルを必要に合うようにカスタマイズできます。

<java-home>/conf/security/java.securityファイルのcrypto.policyセキュリティ・プロパティまたはJava Platform, Standard Editionセキュリティ開発者ガイドの暗号化の強度の構成に関する項を参照してください。

実際の要件を決定する際は、輸出入管理コンサルタントまたは弁護士に相談することをお薦めします。

キーストアにはPKCS12形式を使用することをお薦めします。この形式はデフォルトのキーストア・タイプで、RSA PKCS12 Personal Information Exchange Syntax Standardに基づいています。

Java Platform, Standard Editionセキュリティ開発者ガイドのJSSEで使用するキーストアの作成に関する項、およびJava Platform, Standard Editionツール・リファレンスのkeytoolに関する項を参照してください。

ガベージファースト・ガベージ・コレクタ(G1 GC)は、JDK 9以降のリリースのデフォルトのガベージ・コレクタです。

大部分のユーザーにとって、G1 GCなどの一時停止の少ないコレクタは、JDK 8のデフォルトであったParallel GCなどのスループット指向のコレクタに比べて全体のパフォーマンスが優れています。

G1 GCのチューニングの詳細は、『Java Platform, Standard Edition Java仮想マシン・ガイド』のG1 GCのエルゴノミック・デフォルトに関する項およびチューニング可能なデフォルトに関する項を参照してください。

JDK 9以降のリリースでは、次のGCの組合せの場合に、アプリケーションの起動に失敗します。

CMSのフォアグラウンド・モードも削除されています。削除されたコマンドライン・フラグは、-Xincgc、-XX:+CMSIncrementalMode、 -XX:+UseCMSCompactAtFullCollection、-XX:+CMSFullGCsBeforeCompactionおよび -XX:+UseCMSCollectionPassingです。

コマンドライン・フラグ-XX:+UseParNewGCは有効ではなくなりました。ParNewフラグはCMSとともにのみ使用でき、CMSではParNewが必須です。そのため、-XX:+UseParNewGCフラグは非推奨となっており、今後のリリースで削除対象となっています。

『JEP 214: Remove GC Combinations Deprecated in JDK 8』を参照してください。

Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize; support was removed in 8.0

ガベージ・コレクション(GC)ロギングではJVM統合ロギング・フレームワークを使用しており、新しいログと古いログとでいくらかの違いがあります。現在使用しているGCログ・パーサーは変更がほぼ必要となります。

さらに、JVMロギング・オプションも更新が必要となる可能性があります。GC関連のすべてのロギングにおいて、通常は他のタグと組み合せて、gcタグを(例: —Xlog:gc)使用する必要があります。—XX:+PrintGCDetailsオプションおよび-XX:+PrintGCオプションは非推奨となっています。

Java Platform, Standard Editionツール・リファレンスのJVM Unified Logging Frameworkによるロギングの有効化に関する項および『JEP 271: Unified GC Logging』を参照してください。

javahツールは、javacでより優れた機能によって置き換えられています。JDK 10では削除されました。

JDK 8以降、javacは、Javaソース・コードがコンパイルされた時点でネイティブ・ヘッダー・ファイルを記述する機能を提供します。これによって、別のツールは必要ありません。

javac -h

JavaDB (旧称Apache Derby)は、JDKには含まれなくなりました。

JavaDBはJDK 7およびJDK 8にバンドルされていました。これはJDKインストール・ディレクトリのdbディレクトリにありました。

Apache DerbyはApache Derbyのダウンロードからダウンロードおよびインストールできます。

hprofエージェント・ライブラリは削除されました。

hprofエージェントはJVM Tool Interfaceのデモンストレーション・コードとして記述されたもので、本番ツールとすることを意図したものではありません。hprofエージェントの役立つ機能はより優れた代替品により置き換えられました。その一部はJDKに含まれています。

hprof形式のヒープ・ダンプを作成するには、診断コマンド(jcmd)またはjmapツールを使用します。

• 診断コマンド: jcmd <pid> GC.heap_dump。jcmdに関する項を参照してください。
• jmap: jmap -dump。jmapに関する項を参照してください。

CPUプロファイラ機能については、JDKにバンドルされているJava Flight Recorderを使用してください。

『JEP 240: Remove the JVM TI hprof Agent』を参照してください。

jhatツールはJDK 6で追加された、試験的な未サポートのヒープ視覚化ツールでした。より優れたヒープ・ビジュアライザおよびアナライザが多年にわたって提供されています。

Windowsの起動ツールjava-rmi.exeおよびLinuxとSolarisの起動ツールjava-rmi.cgiが削除されています。

java-rmi.cgiはLinuxおよびSolarisの$JAVA_HOME/binにありました。

java-rmi.exeはWindowsの$JAVA_HOME/binにありました。

これらの起動ツールは、RMI CGIプロキシ・メカニズムの使用を促進するためにJDKに追加されていましたが、JDK 8で非推奨となっていました。

HTTPによるプロキシRMIのかわりにサーブレットの使用が長年にわたって可能であるとともに薦められてきました。Java RMIとオブジェクトのシリアライズに関する項を参照してください。

JMX RMIコネクタからのIIOPトランスポートのサポートが、そのサポート・クラスとともにJDKから削除されました。

JDK 8では、IIOPトランスポートのサポートが必須からオプションにダウングレードされました。これは、JMX Remote APIからIIOPトランスポートのサポートを削除するための複数リリースにわたる取組みの最初のステップでした。JDK 9では、IIOPのサポートが完全に削除されました。

パブリックAPIの変更には次が含まれます。

• javax.management.remote.rmi.RMIIIOPServerImplクラスは非推奨になりました。呼び出すと、そのすべてのメソッドおよびコンストラクタは、説明のメッセージとともにjava.lang.UnsupportedOperationExceptionをスローします。

• 2つのクラスorg.omg.stub.javax.management.rmi._RMIConnection_Stubおよびorg.omg.stub.javax.management.rmi._RMIConnection_Tieは生成されません。

Windows 32ビット・クライアントVMは使用できなくなりました。サーバーVMのみが提供されます。

JDK 8以前のリリースでは、Windows 32ビット・システム用にクライアントJVMとサーバーJVMの両方が提供されていました。JDK 9以降のリリースでは、ピーク・オペレーティング速度を最大化するためにチューニングされているサーバーJVMのみが提供されます。

Java VisualVMは、Java仮想マシン上で実行されているコードについての情報を提供するツールです。jvisualvmツールはJDK 6、JDK 7およびJDK 8で提供されていました。

Java VisualVMはJDKとバンドルされなくなりましたが、VisualVMオープン・ソース・プロジェクト・サイトから入手できます。

native2asciiツールはJDKから削除されました。JDK 9以降のリリースではUTF-8ベースのプロパティ・リソース・バンドルがサポートされているため、UTF-8ベースのプロパティ・リソース・バンドルのISO-8859-1への変換ツールは必要なくなりました。

『Java Platform, Standard Edition国際化ガイド』のUTF-8プロパティ・ファイルに関する項を参照してください。

java.awt.Desktopクラスには、Apple固有のcom.apple.eawtおよびcom.apple.eioパッケージにあるAPIの代替が含まれています。新しいAPIはmacOS APIを置き換えるもので、プラットフォームに依存しません。

com.apple.eawtおよびcom.apple.eioパッケージのAPIはカプセル化されているため、JDK 9以降のリリースでこれらに対してコンパイルすることはできません。ただし、実行時にはアクセス可能であるため、古いバージョンにコンパイルされた既存のコードは引き続き動作します。最終的には、appleおよびcom.appleパッケージおよびそのサブパッケージの内部クラスを使用するライブラリやアプリケーションは新しいAPIへの移行が必要となります。

com.apple.concurrentおよびapple.applescriptパッケージは削除されており、代替はありません。

『JEP 272: Platform-Specific Desktop Features』を参照してください。

プラットフォーム固有のjavax.script実装であるAppleScriptエンジンはJDKで削除されており、代替はありません。

AppleScriptエンジンは、最近のリリースではほぼ使用できませんでした。JDK 7やJDK 8においてこの機能は、AppleバージョンのAppleScriptEngine.jarファイルがシステムにある場合にのみ動作していました。