Java Platform Standard Edition

このガイドの目的は、既存のJavaアプリケーションをJDK 8以前のバージョンのJDKからJDK 10に移行する際の潜在的な問題を識別できるようサポートし、移行の進め方について提案することです。このガイドは、『JDK 9移行ガイド』とほとんど同じです。

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

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

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

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

• JDK 10のダウンロード

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ソース・コードでアンダスコア文字("_")を一文字で識別子として使用している場合、JDK 10ではそのコードはコンパイルできません。このように使用すると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オプションを使用する場合、使用する値を確認してください。

  -source/-targetのサポートされている値は10 (デフォルト)、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 10でも引き続きアクセスできますが、JDKの大部分の内部APIにはコンパイル時にはアクセスできません。アプリケーションまたはそのライブラリが内部APIに依存していることを示すコンパイル・エラーが発生することがあります。

  依存関係を特定するには、Java依存性分析ツールを実行します。「コードに対するjdepsの実行」を参照してください。可能であれば、サポートされている代替APIを使用するようにコードを更新してください。

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

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

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

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

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

アプリケーションに対して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 10では、時間ベースの解放モデルへの対応を改善するために、JDK 9で導入されたバージョン文字列のスキームが少し変更されています。コードでメジャー、マイナー、セキュリティおよびパッチ更新を識別するのにバージョン文字列形式に依存している場合、更新が必要となる可能性があります。

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

$FEATURE.$INTERIM.$UPDATE.$PATCH

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

Java Platform, Standard Editionインストレーション・ガイドのバージョン文字列の書式を参照してください。

JDK 10で導入されたバージョン文字列の変更の詳細は、JEP 322: 時間ベースのリリースのバージョニングを参照してください。

JDK 9で導入されたバージョン文字列に対する変更の詳細は、JEP 223: 新規バージョン文字列のスキームを参照してください。

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

たとえば、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といった他のコマンドライン・オプションで有効になっているものを除き、すべてのリフレクション・アクセス操作が無効になります。これは将来のリリースにおいてデフォルト・モードになる予定です。

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

デフォルトでアクセスできないようになっている内部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およびJREに大きな変更が加えられています。

JDKのインストール後にファイル・システムを参照するとわかるとおり、ディレクトリ・レイアウトが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リリース・ノートを参照してください。

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

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

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

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

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

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

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

java.* APIとは異なり、ほとんどすべてのsun.* APIはサポートされていないJDK内部APIであり、いつでもなくなる可能性があります。

一部のsun.* APIがJDK 9で削除されました。注意が必要な点として、sun.misc.BASE64Encoderおよびsun.misc.BASE64Decoderが削除されています。かわりに、JDK 8で追加された、サポートされているjava.util.Base64クラスを使用してください。

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

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

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

非標準パッケージ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

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

JDK 9とJDK 10では、クラス・パスにあるコードをコンパイルまたは実行するとき、CORBAを含む、またはJava SEとJava EEの間で共有されるAPIを含むモジュールは、デフォルトでは解決されません。これらのモジュールは削除できません。これらのモジュールを解決しないというこのポリシーは、これらのAPIを今後のリリースのJava SEおよびJDKから削除するための最初の一歩です。

非推奨となったモジュールは、次のとおりです。

• 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により失敗します。

JEP 320: Java EEおよびCORBAモジュールの削除を参照して、移行オプションとモジュールについて可能な置換の詳細を確認し、JDKからのJava EEおよびCORBAモジュールの削除の進捗を追跡します。

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

Javaデプロイメント・テクノロジが非推奨になりました。今後のリリースでは削除されます。

javawsツールを含むアプレットAPI、Javaプラグイン、Javaアプレット・ビューア、JNLP、Java Web Startなど、JavaアプレットおよびWeb Start機能は、JDK 9ですべて非推奨となり、将来のリリースでは削除されます。

事前インストールされたシステムJREに依存するのではなく、JDK 9で導入されたjlinkツールを使用して、専用のランタイムをパッケージ化してデプロイしてください。

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に関する項を参照してください。

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

ガベージファースト・ガベージ・コレクタ(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プロパティ・ファイルに関する項を参照してください。

この項では、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』を参照してください。

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

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

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

• JDK 10の新機能および変更点の詳細は、JDK 10の新機能を参照してください。

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