Java Platform Standard Edition

Oracle JDK 9移行ガイド

リリース9

E90930-02(原本部品番号:E82965-05)

2017年10月

JDK 9への移行

このガイドの目的は、既存のJavaアプリケーションをJDK 9に移行する際の潜在的な問題を識別できるようサポートし、移行の進め方について提案することです。

新しいJava SEがリリースされると必ず、以前のリリースとのバイナリ、ソース、および動作上の非互換が発生します。Java SEプラットフォームのモジュール化には多くのメリットがありますが、同時に多くの変更も伴います。公式のJava SEプラットフォームAPIおよびサポートされているJDK固有のAPIのみを使用するコードは、変更なしでそのまま動作します。JDK内部APIを使用するコードは引き続き動作しますが、外部APIを使用するように移行する必要があります。

アプリケーションを移行するには、「移行の準備」にリストされている手順から開始します。

それから、アプリケーション実行の際に遭遇する可能性のある変更のリストを確認します。

- バージョン文字列の新しいスキーム

- ランタイム・アクセス警告の理解

- インストール済JDK/JREイメージに加えられた変更

- 削除または変更されたAPI

- Java EEと共有するモジュールがデフォルトでは解決されない

- デプロイ

- セキュリティ・アップデート

- ガベージ・コレクションへの変更

- 削除されたツールとコンポーネント

- 削除されたmacOS固有の機能

アプリケーションがJDK 9で正常に動作するようになったら、最後に、「今後のために」を確認してください。今後のリリースにおいて問題が発生するのを回避するのに役立ちます。

このガイドでは、コードをJDK 9で実行できるようにするのに必要となる変更について取り上げます。JDK 9のすべての新機能の包括的なリストについては、『Java Platform, Standard Edition JDK 9の新機能』を参照してください。このガイドで言及されている変更の詳細は、JDK 9リリース・ノートを参照してください。

移行の準備

次の項は、アプリケーションの移行を成功させるのに役立ちます。

- JDK 9のダウンロード

- 再コンパイルする前のプログラムの実行

- サードパーティ・ライブラリの更新

- アプリケーションのコンパイル(必要に応じて)

- コードに対するjdepsの実行

JDK 9のダウンロード

JDK 9リリースをダウンロードしてインストールします。

再コンパイルする前のプログラムの実行

アプリケーションをJDK 9で実行してみます。たいていのコードおよびライブラリは変更しなくてもJDK 9上で動作するはずですが、一部のライブラリはアップグレードの必要があります。

注意:

移行は反復的なプロセスです。プログラムをまず実行してみてから(このタスク)、これらの3つのタスクをある程度平行して進めるのがおそらく最善でしょう。

- サードパーティ・ライブラリの更新

- アプリケーションのコンパイル(必要に応じて)

- コードに対するjdepsの実行

アプリケーションの実行時に、廃止されたVMオプションに関するJVMからの警告がないか確認します。VMの起動に失敗する場合は、削除されたオプションがないか探してください。JDK 8で非推奨となった一部のVMフラグがJDK 9で削除されているためです。「削除されたGCオプション」を参照してください。

アプリケーションが正常に起動する場合は、慎重にテストして動作がJDK 8のときと同じであることを確認します。たとえば、一部の早期導入者は日付および通貨の形式が違っていることに気付いてきました。「デフォルトでのCLDRロケール・データの使用」を参照してください。

プログラムが正常に動作しているようであっても、このガイドの残りの手順を完了して問題のリストを確認するようにしてください。

サードパーティ・ライブラリの更新

使用するすべてのツールおよびサードパーティ・ライブラリについて、JDK 9をサポートする更新版が必要となる可能性があります。

JDK 9で動作するように設計された各ライブラリまたはツールのバージョンについては、サードパーティ・ライブラリおよびツール・ベンダーのWebサイトを確認してください。提供されている場合は、その新しいバージョンをダウンロードおよびインストールしてください。

アプリケーションを構築するのにMavenまたはGradleを使用している場合、JDK 9をサポートしているさらに新しいバージョンにアップグレードしてください。

アプリケーションを開発するのにIDEを使用しているなら、既存のコードを移行するのに役立ちます。NetBeans、EclipseおよびIntelliJのIDEはいずれも、JDK 9サポートを含むバージョンが提供されています。

OpenJDK Wikiの品質支援に関する項で、多くのフリー・オープン・ソース・ソフトウェア(FOSS)プロジェクトをテストしたステータスを確認できます。

アプリケーションのコンパイル(必要に応じて)

問題があることがわかっているAPIや機能にコードが依存している可能性があるため、JDK 9コンパイラでコードをコンパイルすると、将来のリリースへの移行が容易になります。ただし、必ず必要というわけではありません。

コードをJDK 9コンパイラでコンパイルする必要がある場合、次の点に注意してください。

- ソース・コードでアンダスコア文字("_")を一文字で識別子として使用している場合、JDK 9ではそのコードはコンパイルできません。このように使用するとJDK 8では警告となり、JDK 9ではエラーとなります。
次に例を示します。

static Object _ = new Object();

このコードではコンパイラにより次のエラー・メッセージが生成されます。

MyClass.java:2: error: as of release 9, '_' is a keyword, and may not be used as a legal identifier.

- javacで-sourceおよび-targetオプションを使用する場合、使用する値を確認してください。JDK 9において、javacでは-sourceおよ-targetオプションのサポートに"one plus three back" (3世代前まで)ポリシーが採用されています。
-source/-targetのサポートされている値は9 (デフォルト)、8、7および6です(6は非推奨で、この値が使用されると警告が表示されます)。

JDK 8では、-sourceおよび-targetの値に1.5/5以前の値を指定するのは非推奨となり、警告が生成されました。JDK 9では、これらの値はエラーになります。

>javac -source 5 -target 5 Sample.java
warning: [options] bootstrap class path not set in conjunction with -source 1.5
error: Source option 1.5 is no longer supported. Use 1.6 or later.
error: Target option 1.5 is no longer supported. Use 1.6 or later.

できるだけ、-sourceおよび-targetオプションのかわりに新しい--releaseフラグを使用するようにしてください。--release Nフラグは概念としては次のマクロになります。

-source N -target N -bootclasspath $PATH_TO_rt.jar_FOR_RELEASE_N

--releaseフラグの有効な引数には、-sourceおよび-targetと同じく、"one plus three back"ポリシーが適用されます。

javacは、JDK 1.0.2クラス・ファイルまでさかのぼる、以前のすべてのJDKのクラス・ファイルを認識および処理できます。

『JEP 182: Policy for Retiring javac -source and -target Options』を参照してください。

- sun.misc.Unsafeなどの重要な内部JDK APIにはJDK 9でも引き続きアクセスできますが、JDKの大部分の内部APIにはコンパイル時にはアクセスできません。アプリケーションまたはそのライブラリが内部APIに依存していることを示すコンパイル・エラーが発生することがあります。
依存関係を特定するには、Java依存性分析ツールを実行します。「コードに対するjdepsの実行」を参照してください。可能であれば、サポートされている代替APIを使用するようにコードを更新してください。

JDK内部クラスへの参照があるソース・コードをコンパイルするための一時的な回避策として、--add-exportsオプションを使用できます。

- 以前より多くの非推奨メッセージが表示される可能性があります。削除の警告を伴う非推奨がある場合は、今後問題となるのを回避するためにそれらに対処する必要があります。

- javacに、Java SE 9の言語仕様に合わせていくつかの小さな変更が加えられました。

- 再コンパイル時にソース互換性の問題が発生する可能性があります。

JDK 9リリース・ノートには、JDK 9における、javacコンパイラに加えられた変更およびソース互換性の問題の詳細が記載されています。

コードに対するjdepsの実行

アプリケーションに対してjdepsツールを実行して、アプリケーションおよびライブラリが依存するパッケージおよびクラスを確認します。内部APIを使用している場合、jdepsにより、コードを更新する際に役立つ修正候補が表示されることがあります。

内部JDK APIの依存性を検出するには、jdepsを-jdkinternalsオプションとともに実行します。たとえば、sun.misc.BASE64Encoderを呼び出すクラスに対してjdepsを実行すると、次のように表示されます。

>jdeps -jdkinternals Sample.class
Sample.class -> JDK removed internal API
Sample  -> sun.misc.BASE64Encoder  JDK internal API (JDK removed internal API)

Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependency on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
sun.misc.BASE64Encoder                   Use java.util.Base64 @since 1.8

Mavenを使用している場合、利用可能なjdepsプラグインがあります。

jdepsの構文については、Java Platform, Standard Editionツール・リファレンスのjdepsに関する項を参照してください。

jdepsは静的分析ツールであり、コードの静的分析によりすべてがわかるわけではありません。コードでリフレクションを使用して内部APIが呼び出されている場合、jdepsでは警告は表示されません。

バージョン文字列の新しいスキーム

JDK 9では新しいシンプルなバージョン文字列形式が導入されました。コードでメジャー、マイナー、セキュリティおよびパッチ更新を識別するのにバージョン文字列形式に依存している場合、更新が必要となる可能性があります。

新しいバージョン文字列の形式は次のとおりです。

$MAJOR.$MINOR.$SECURITY.$PATCH

たとえば、古いスキームでは、9u5セキュリティ・リリースのバージョン文字列は1.9.0_5-b20となります。

新しいスキームでは、同じリリースの短いバージョンは9.0.1、長いバージョンは9.0.1+20となります。

この変更は、java -versionと、java.runtime.version、java.vm.version、java.specification.versionおよびjava.vm.specification.versionといった関連システム・プロパティに影響します。

バージョン文字列を解析、検証および比較するための単純なJava APIが追加されました。java.lang.Runtime.Versionに関する項を参照してください。

『Java Platform, Standard Editionインストレーション・ガイド』のバージョン文字列の形式に関する項および『JEP 223: New Version-String Scheme』を参照してください。

ランタイム・アクセス警告の理解

一部のツールやライブラリでは、リフレクションを使用して内部使用のみを目的としたJDKの部分にアクセスします。この不正なリフレクション・アクセスはJDKの将来のリリースにおいて無効となる予定です。JDK 9においてこれはデフォルトで許可されており、警告が発行されます。

たとえば、Jython開始時に次のような警告が出力されたとします。

>java -jar jython-standalone-2.7.0.jar
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/C:/Jython/jython2.7.0/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD()
WARNING: Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11)

このような警告が表示された場合は、ツールまたはライブラリの保守担当者に連絡してください。警告の2行目は、JDKの内部部分にアクセスするためにコードでリフレクションが使用されている正確なJARファイルの名前を示しています。

デフォルトでは、java起動ツールによって開始されたプロセスの存続期間中に発行されたリフレクション・アクセスに関する警告が最大1つ発行されます。警告の実際のタイミングは、リフレクション・アクセス操作を実行するツールおよびライブラリの動作によって異なります。この警告は、プロセスのライフタイムの早期に表示されることもあれば、起動後かなりたってから表示されることもあります。

この警告メッセージは、--add-opensコマンドライン・フラグを使用してライブラリごとに無効にできます。たとえば、Jythonを次のようにして起動できます。

>java --add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED -jar jython-standalone-2.7.0.jar
Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11)

今回は、java呼出しで明示的にリフレクション・アクセスが認識されるため、警告は発行されません。この例のように、クラス・パスのライブラリによって試行されるすべてのリフレクション・アクセス操作に対応するために、複数の--add-opensフラグの指定が必要になる場合があります。

ツールおよびライブラリの動作についてさらに理解を深めるには、--illegal-access=warnコマンドライン・フラグを使用できます。このフラグを使用すると、すべての不正なリフレクション・アクセス操作に対して警告メッセージが表示されます。さらに、--illegal-access=debugを設定することで、スタック・トレースなどの、不正なリフレクション・アクセス操作に関する詳細情報を取得できます。

ライブラリを更新した場合やライブラリを入手した場合は、--illegal-access=denyコマンドライン・フラグを使用して試してみることができます。これにより、--add-opensといった他のコマンドライン・オプションで有効になっているものを除き、すべてのリフレクション・アクセス操作が無効になります。これは将来のリリースにおいてデフォルト・モードになる予定です。

カプセル化解除を可能にする具体的なオプションが2つあります。これらをすでに言及したとおり--illegal-access=denyと組み合せて使用して、警告を抑制できます。

- アクセスできない内部APIを使用する必要がある場合、--add-exportsランタイム・オプションを使用します。コンパイル時に--add-exportsを使用して内部APIにアクセスすることもできます。

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

すべてのリフレクション・アクセス警告を抑制する場合は、必要に応じて--add-exportsおよび--add-opensオプションを使用します。

--add-exports

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

--add-exportsオプションの構文は次のとおりです。

--add-exports <source-module>/<package>=<target-module>(,<target-module>)*
ここで、<source-module>および<target-module>はモジュール名、<package>はパッケージの名前です。

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

特殊なケースとして、<target-module>がALL-UNNAMEDの場合、ソース・パッケージが名前のないすべてのモジュールに、それが最初から存在するか後から作成されたかにかかわらずエクスポートされます。次に例を示します。

--add-exports java.management/sun.management=ALL-UNNAMED
この例では、名前のないすべてのモジュールのコード(クラス・パスにあるコード)がjava.management/sun.managementのpublicタイプのpublicメンバーにアクセスできるようにします。クラス・パスにあるコードがディープ・リフレクションによる非publicメンバーへのアクセスを試行すると、そのコードは失敗します。

クラス・パスで実行されるアプリケーションoldAppが、java.managementモジュールのエクスポートされていないcom.sun.jmx.remote.internalパッケージを使用する必要がある場合、必要なアクセス権を次のように付与できます。

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

JARファイル・マニフェストを使用してカプセル化を解除することもできます。

Add-Exports:java.management/sun.management

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

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

--add-opens

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

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

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

--add-opensオプションの構文は次のとおりです。

--add-opens module/package=target-module(,target-module)*
このオプションでは、モジュール宣言にかかわらず、<module>で<package>を<target-module>に開くことを許可します。

特殊なケースとして、<target-module>がALL-UNNAMEDの場合、ソース・パッケージが名前のないすべてのモジュールに、それが最初から存在するか後から作成されたかにかかわらずエクスポートされます。次に例を示します。

--add-opens java.management/sun.management=ALL-UNNAMED
この例では、クラス・パスにあるすべてのコードがjava.management/sun.managementパッケージのpublicタイプの非publicメンバーにアクセスできるようにします。

注意:
たとえばJava Web StartのJNLPファイルなど、JNI呼出しAPIを使用している場合、--add-opensとその値の間に等号を含める必要があります。

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

コマンドラインでは等号はオプションです。

インストール済JDK/JREイメージに加えられた変更

JDKおよびJREに大きな変更が加えられています。

JDKおよびJREレイアウトの変更

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

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

JDK 9では、JDKとJREは2種類のモジュラ・ランタイム・イメージで、それぞれに次のディレクトリが含まれます。

- bin — バイナリ実行可能ファイルが含まれます。

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

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

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

『JEP 220: Modular Run-Time Images』および『Java Platform, Standard Editionインストレーション・ガイド』のJDKおよびJREのインストール済ディレクトリの構造に関する項を参照してください。

新しいクラス・ローダー実装

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が設定されたクラス・ローダーを作成するアプリケーションは、前述のように変更が必要となる可能性があります。

JDK 9リリース・ノートを参照してください。

rt.jarおよびtools.jarの削除

以前に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 9では、拡張クラスを使用する必要がある場合、JARファイルがクラス・パスにあることを確認してください。

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

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

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

Windowsレジストリ・キーの変更

JREインストーラは、前のリリースとは異なる名前のキーをWindowsレジストリに作成します。これらの変更では、これらのキーを使用する既存のアプリケーションに影響する場合があります。

ご使用のアプリケーションが、Javaのインストール・バージョンをレジストリで検索すると、Java SE 8および前のリリースで作成されたJava Runtime EnvironmentキーがJava SE 9ではJREに簡略化されているために失敗する場合があります。

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

- "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE"

- "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE\9"

- "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE"
"@CurrentVersion"=9

JDKがインストールされると、JDKキーで前出の例のJREキーが置き換えられます。

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

- "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment"

- "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8"

- "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_144"

- "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment"
"@CurrentVersion"=1.8

JDKがインストールされると、Java Development Kitキーで前出の例のJava Runtime Environmentキーが置き換えられます。

JDKまたはJREの2つのバージョンがインストールされている場合で、一方がJDK 9で導入された新しいバージョン文字列形式を使用していて、もう一方が古いバージョン形式を使用している場合、Javaに関連した2つの異なるCurrentVersion文字列がレジストリに存在します。一方がJDK 9より前でもっとも大きいバージョン番号を示し、もう一方がJDK 9以降でもっとも大きいバージョン番号を示します。

削除または変更されたAPI

この項では、アクセス不可となった、削除された、またはデフォルト動作が変更された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が削除されています。かわりに、Java SE 8で追加された、サポートされているjava.util.Base64クラスを使用してください。

これらのAPIを使用している場合、サポートされている代替機能に移行することを考慮してください。

- sun.misc.Unsafe
このクラスの多くのメソッドの機能は変数ハンドルを使用することで実現できます。『JEP 193: Variable Handles』を参照してください。

- sun.reflect.Reflection::getCallerClass(int)
かわりにスタックウォーキングAPIを使用します。『JEP 259: Stack-Walking API』を参照してください。

『JEP 260: Encapsulate Most Internal APIs』を参照してください。

java.awt.peerはアクセス不可

java.awt.peerおよびjava.awt.dnd.peerパッケージはJDK 9ではアクセスできません。このパッケージはjava.*ネームスペースにありますが、Java SE APIの一部であったことはありません。

これらのパッケージで定義されている型を参照するJava SE APIのすべてのメソッドが、JDK 9から削除されています。これらのパッケージで定義された型をこれまで受け付けたり返していたメソッドを呼び出すコードは、コンパイルや実行ができなくなりました。

java.awt.peerクラスの一般的な使用方法は2種類です。これらは次のように修正してください。

- ピアがまだ設定されているかどうかを調べるには:

if (component.getPeer() != null) { .. }
これをJDK 1.1 APIのComponent.isDisplayable()で置き換えてください。

public boolean isDisplayable() {
return getPeer() != null;

- コンポーネントが軽量かどうかをテストするには:

if (component.getPeer() instanceof LightweightPeer) ..
これをJDK 1.2 APIのComponent.isLightweight()で置き換えてください。

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

Java SE 8の各プロファイルで指定されているパッケージは、次のモジュール・セットにより集合的にエクスポートされます。

- 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 Platform, Standard Editionツール・リファレンスの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』を参照してください。

Java EEと共有するモジュールがデフォルトでは解決されない

JDK 9において、クラス・パスにあるコードをコンパイルまたは実行する際に、CORBAまたはJava SEとJava EE間で共有されるAPIを含むモジュールは、デフォルトでは解決されません。該当するものは次のとおりです。

- java.corba — CORBA

- java.transaction — CORBA Object Transaction Servicesをサポートするための、Java SEによって定義されているJava Transaction APIのサブセット

- java.activation — JavaBeans Activation Framework

- java.xml.bind — Java Architecture for XML Binding (JAXB)

- java.xml.ws — Java API for XML Web Services (JAX-WS)、Web Services Metadata for the Java PlatformおよびSOAP with Attachments for Java (SAAJ)

- java.xml.ws.annotation — Webサービスをサポートするための、Java SEによって定義されているJSR-250 Common Annotationsのサブセット

これらのAPIのクラスへの参照を含む既存のコードは、ビルドを変更しなければコンパイルされません。同様に、これらのAPIのクラスへの参照があるクラス・パスのコードは、アプリケーションのデプロイ方法に変更を加えないかぎり、NoDefClassFoundErrorまたはClassNotFoundExceptionにより失敗します。

これらのAPIのコードはJDK 9では削除されていませんが、モジュールは削除予定として非推奨となっています。これらのモジュールを解決しないというこのポリシーは、これらのAPIを今後のリリースのJava SEおよびJDKから削除するための最初の一歩です。

これらのAPIを使用するライブラリやアプリケーションの移行オプションは次のとおりです。

1. --add-modulesコマンドライン・オプションを使用して、APIを含むモジュールが起動時に解決されるようにします。たとえば、--add-module java.xml.bindと指定すると、java.xml.bindモジュールが解決されます。これにより、JAXB APIを使用する既存のコードおよび実装がJDK 8の場合と同じように動作します。
これらのモジュールは最終的にはJDKから削除される予定のため、これは一時的な回避策です。

回避策として--add-modules java.se.eeまたは--add-modules ALL-SYSTEMを使用することは薦められていません。これらのオプションはすべてのJava EEモジュールを解決するものであり、これはスタンドアロン・バージョンのAPIも使用している環境において問題となります。

2. クラス・パスにあるスタンドアロン・バージョンのAPI(および必要に応じて実装)をデプロイしてください。各Java EE APIは、Maven Centralで公開されているプロジェクトによるスタンドアロンのテクノロジです。

3. アップグレード・モジュール・パスにこれらのモジュールのスタンドアロン・バージョンをデプロイします。スタンドアロン・バージョンはJava EEプロジェクトにより提供されています。

デプロイ

この項では、アプリケーションのデプロイ時にのみ出現する問題を説明します。

起動時のJREバージョン選択の削除

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

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

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

JDK 9では、java起動ツールが次のように変更されています。

- コマンドラインで-version:オプションが指定されているとエラー・メッセージを出力して終了します。

- JRE-Versionマニフェスト・エントリがJARファイルにあると、警告メッセージを出力して続行します。

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

シリアライズされたアプレットのサポートの削除

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

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

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

JNLP仕様の更新

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

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

1. JNLPファイルにおける&のかわりの&amp;の使用。
JNLPファイル構文はXML仕様に準拠しており、すべてのJNLPファイルは標準のXMLパーサーによる解析が可能である必要があります。

JNLPファイルでは複雑な比較を指定できます。これまでこれはアンパサンド(&)を使用して行われていましたが、これは標準XMLではサポートされていません。&を使用して複雑な比較を作成している場合、JNLPファイルで&amp;に置き換えてください。&amp;はすべてのバージョンの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仕様の更新に関する項を参照してください。

セキュリティ・アップデート

JDK 9において一部のセキュリティ関連のデフォルトが変更されています。

JCE Jurisdiction Policy FilesのデフォルトはUnlimited

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

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

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

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

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

PKCS12キーストアの作成

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

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

ガベージ・コレクションへの変更

この項では、JDK 9でガベージ・コレクションに加えられた変更について説明します。

デフォルトのガベージ・コレクタがG1に

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

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

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

削除されたGCオプション

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

- DefNew + CMS

- ParNew + SerialOld

- インクリメンタルCMS

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

Permanent世代の削除

Permanent世代はJDK 8で削除されており、関連するVMオプションでは警告が表示されます。次のオプションはスクリプトから削除する必要があります。

- -XX:MaxPermSize=size

- -XX:PermSize=size

JDK 9では、JVMにより次のような警告が表示されます。

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

Permanent世代を認識するツールは更新が必要となる可能性があります。

『JEP 122: Remove the Permanent Generation』およびJDK 9リリース・ノート - 削除されたAPI、機能およびオプションを参照してください。

GCログ出力の変更

ガベージ・コレクション(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』を参照してください。

削除されたツールとコンポーネント

このリストには、JDK 9にバンドルされなくなったツールおよびコンポーネントが示されています。

JavaDBの削除

JavaDB (旧称Apache Derby)は、JDK 9には含まれていません。

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

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

JVM TI hprofエージェントの削除

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を使用してください。

注意:
Java Flight Recorderを本番で使用するには、商用ライセンスが必要です。商用機能の詳細とそれらを有効化する方法については、http://www.oracle.com/technetwork/java/javaseproducts/にアクセスしてください。

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

jhatツールの削除

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

java-rmi.exeおよびjava-rmi.cgi起動ツールの削除

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 RMIConnectorからのIIOPトランスポートのサポートの削除

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

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の削除

JDK 9では、Windows 32ビット・クライアントVMは使用できません。サーバーVMのみが提供されます。

JDK 8以前のリリースでは、Windows 32ビット・システム用にクライアントJVMとサーバーJVMの両方が提供されていました。JDK 9ではサーバーJVMのみが提供されます。サーバーJVMは、ピーク時の動作速度が最大となるように調整されています。

Java VisualVMの削除

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

Java VisualVMはJDK 9にはバンドルされていません。JDK 9でVisualVMを使用する必要がある場合は、VisualVMオープン・ソース・プロジェクト・サイトから入手できます。

native2asciiツールの削除

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

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

削除されたmacOS固有の機能

この項では、JDK 9で削除されたmacOS固有の機能について説明します。

プラットフォーム固有のデスクトップ機能

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

AppleScriptエンジンの削除

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

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

今後のために

アプリケーションがJDK 9で動作するようになったら、Java SEプラットフォームを最大限活用するためのいくつかの提案があります。

- 『Java Platform, Standard Edition JDK 9の新機能』をお読みになり、JDK 9の新機能について学習してください。

- 必要に応じて、javacツールで新しい–releaseフラグを使用して、古いリリースのプラットフォームにクロス・コンパイルしてください。

- コードを最新の機能により更新するには、IDEの提案を活用してください。

- コードが非推奨のAPIを使用しているかどうかを確認するには、静的分析ツールjdeprscanを実行します。このガイドで言及したとおり、APIがJDKから削除されることもありますが、必ず事前の予告があります。

- マルチリリースJARファイル(jarを参照)などの新機能に慣れ親しむようにしてください。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracleサポートへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

Java Platform, Standard Edition Oracle JDK 9移行ガイド,リリース9

E90930-02

Copyright © 2017, Oracle and/or its affiliates. All rights reserved.

このガイドは、アプリケーションをOracle JDK 9に移行するのに役立ちます。

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2018, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。