Java Platform Standard Edition

Oracle JDK 移行ガイド

リリース11

F11787-03(原本部品番号:E94894-03)

2019年7月

はじめに

このガイドの目的は、既存のJavaアプリケーションを最新のJDKリリースに移行する際の潜在的な問題を識別できるようサポートし、移行の進め方について提案することです。また、最新リリースに対して行われた重要な変更および機能拡張についても説明します。

このガイドには、次のセクションがあります。

JDK 11リリースにおける重要な変更

アプリケーションをJDK 11に以降する前に、JDK 11とJDK 10のリリース間における更新内容および変更点について理解する必要があります。JDK 8から移行する場合は、JDK 8と後続リリースとの間の相違点(「JDK 8から後続のJDKリリースへの移行」を参照)についてよく理解しておくことも必要です。

次に、JDK 11での重要な変更点の一部を示します。

  • JREおよびServer JREのダウンロードが提供されなくなったため、今後は自動更新を使用できません。

  • 32ビットWindows版ダウンロードは提供されなくなりました。

  • Java Web Start、JavaプラグインおよびJavaコントロール・パネルはJDKで提供されません。「デプロイメント・スタックの削除」を参照してください。

  • JavaFXはJDKで提供されなくなりました。現在は、https://openjfx.io/から個別のダウンロードとして入手できます。

  • JAXBおよびJAX-WSはJDKにバンドルされなくなりました。「Java EEおよびCORBAモジュールの削除」を参照してください。

また、セキュリティ関連の更新が行われ、いくつかのツールとコンポーネントが削除されたので、それらを確認しておく必要があります。次を参照してください。

デプロイメント・スタックの削除

Javaデプロイメント・テクノロジはJDK 9で非推奨になり、JDK 11で削除されました。

JavaアプレットおよびWeb Start機能(Javaプラグイン、Javaアプレット・ビューア、Javaコントロール・パネル、Java Web Startなど)は、javawsツールとともにJDK 11で削除されました。

Javaデプロイメント・テクノロジの削除に関する項を参照してください。

Java EEおよびCORBAモジュールの削除

JDK 11では、Java EEおよびCORBAモジュールが削除されました。これらのモジュールはJDK 9で削除予定の非推奨となりました。

削除されたモジュールは次のとおりです。

  • 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.bind: Java Architecture for XML Binding (JAXB)
  • java.xml.ws.annotation: Webサービスをサポートするための、Java SEによって定義されているJSR-250 Common Annotationsのサブセット
  • java.corba: CORBA
  • java.transaction: CORBA Object Transaction Servicesをサポートするための、Java SEによって定義されているJava Transaction APIのサブセット
  • java.activation: JavaBeans Activation Framework
  • java.se.ee: 前述の6つのモジュール用のアグリゲータ・モジュール
  • jdk.xml.ws: JAX-WS用のツール
  • jdk.xml.bind: JAXB用のツール

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

使用可能な代替モジュールの詳細は、『JEP 320: Remove the Java EE and CORBA Modules』を参照してください。

注意:

JAXBおよびJAX-WSはMavenからダウンロードできます。

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

JDK 11リリースでのセキュリティ・アップデート

JDK 11リリースには、TLS (Transport Layer Security) 1.3仕様(RFC 8446)の実装が含まれています。

TLS 1.3はトランスポート層セキュリティ(TLS)プロトコルの最新のイテレーション(2018年8月)であり、JDK 11ではデフォルトで有効化されています。このバージョンでは、速度の向上に重点が置かれているだけでなく、最新の暗号化手法を重視してプロトコルのセキュリティ全体が更新されており、古いまたは脆弱な暗号化アルゴリズムは使用できません。(たとえば、RSAキー交換やプレーンなDSA署名は使用できなくなりました。)

TLS 1.3プロトコルには、下位互換性を向上させるための複数の機能が追加されていますが、いくつかの問題について留意しておく必要があります。詳細は、JEP 332を参照してください。

セキュリティ証明書の削除

JDK 11では、次のルート証明書がキーストアから削除されました。

JDK 11では、次のルート証明書がトラストストアから削除されました。

削除された証明書を使用している製品は機能しなくなる可能性があります。これらの証明書が必要な場合は、無効になった証明書を使用してcacertsを構成し、移入する必要があります。トラストストアに証明書を追加するには、『Java Platform, Standard Editionツール・リファレンス』ガイドのkeytoolに関する項を参照してください。

削除されたAPI、ツールおよびコンポーネント

この項では、JDK 11で削除されたAPI、ツールおよびコンポーネントについて詳しく説明します。

JDK 11で削除されたAPI

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)

JDK 11に同梱されないツールおよびコンポーネント

JDK 11に同梱されないツールおよびコンポーネントを次に示します。

主要ツール

  • appletviewer

JDK-8200146 : appletviewer起動ツールの削除を参照してください。

CORBAツール

  • idlj
  • orbd
  • servertool
  • tnamesrv

また、rmic (RMIコンパイラ)で-idl-iiopオプションがサポートされなくなりました。JDK 11リリース・ノートを参照してください。

Java Web Servicesツール

  • schemagen
  • wsgen
  • wsimport
  • xjc

『JEP 320: Remove the Java EE and CORBA Modules』を参照してください。

Javaデプロイメント・ツール

  • javapackager
  • javaws

注意:

pack 200およびunpack200非推奨になり、将来のJDKリリースで削除される可能性があります。

JDKからのJavaFXの削除に関する項および『JEP 336: Deprecate the Pack200 Tools and API』を参照してください。

モニタリング・ツール

  • jmc: JMCは、JDK 11でスタンドアロン・パッケージとして提供され、JDKにバンドルされていません。

JDKからのJMCの削除に関する項および『Java Mission Control』を参照してください。

JVM-MANAGEMENT-MIB.mib

SNMP JVM-MANAGEMENT-MIB.mibを使用したJVMモニタリングおよび管理の仕様は削除されました。JVM-MANAGEMENT-MIB.mibの削除を参照してください。

SNMPエージェント

jdk.snmpモジュールは削除されました。SNMPエージェントの削除を参照してください。

Oracleデスクトップ固有の削除

  • Oracle JDK T2Kフォント・ラスタライザは削除されました。
  • Lucidaフォント: Oracle JDK付属のフォントがなくなり、オペレーティング・システムにインストールされているフォントに完全に依存するようになりました。Oracle JDKからのLucidaフォントの削除に関する項を参照してください。

移行の準備

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

最新のJDKのダウンロード

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

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

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

注意:

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

アプリケーションの実行時に、廃止されたVMオプションに関するJVMからの警告がないか確認します。VMの起動に失敗する場合は、「削除されたGCオプション」を確認してください。

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

最新のJDKリリースでコードを動作させるには、各JDKリリースの新機能および変更点を確認します。

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

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

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

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

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

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

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

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

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

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

  • ソース・コードでアンダスコア文字("_")を一文字で識別子として使用している場合、JDK 11ではそのコードはコンパイルできません。このように使用すると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のサポートされている値は11 (デフォルト)、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 5 
    error: Source option 5 is no longer supported. Use 6 or later. 
    error: Target option 1.5 is no longer supported. Use 1.6 or later.

    できるだけ、-sourceおよび-targetオプションのかわりに新しい--releaseフラグを使用するようにしてください。Java Platform, Standard Editionツール・リファレンスjavacを参照してください。

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

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

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

  • 以前より多くの非推奨メッセージが表示される可能性があります。

コードに対する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 8から後続のJDKリリースへの移行

JDK 8と後続のJDKリリースとの間では、重要な変更が行われました。

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

次の各項では、JDK 8アプリケーションを後続のJDKリリースに移行する際に注意する必要があるJDKパッケージおよびAPIの変更点について説明します。

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

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

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

カプセル化解除を可能にする具体的なオプションが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="10" java-vm-args="--add-opens=module/package=ALL-UNNAMED"  />

--add-opensとその値の間の等号記号は、コマンド・ラインのオプションです。

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

JDK 10では、時間ベースの解放モデルへの対応を改善するために、JDK 9で導入されたバージョン文字列のスキームが少し変更されています。JDK 11ではJDK 10で導入されたバージョン文字列の書式が保持されます。

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

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

$FEATURE.$INTERIM.$UPDATE.$PATCH

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

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

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

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

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

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

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

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 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.jarlib/tools.jarlib/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で削除された拡張機能メカニズム

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

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

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"

削除または変更されたAPI

この項では、アクセス不可となった、削除された、またはデフォルト動作が変更されたAPIについて説明します。アプリケーションのコンパイルまたは実行時に、この項で説明されている問題が発生する可能性があります。

「JDK 11で削除されたAPI」を参照してください。

JDK 9およびJDK 10で削除されたAPI

JDK 9およびJDK 10リリースから削除された重要な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クラスを使用してください。

これらの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のツールでは、compact1compact2および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.basejava.loggingjava.scripting

  • compact2プロファイル: java.basejava.loggingjava.scriptingjava.rmijava.sqljava.xml

  • compact3プロファイル: java.basejava.loggingjava.scriptingjava.rmijava.sqljava.xmljava.compilerjava.instrumentjava.managementjava.namingjava.prefsjava.security.jgssjava.security.sasljava.sql.rowsetjava.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デプロイメント・テクノロジはJDK 9で非推奨になり、JDK 11で削除されました。

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

起動時の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要素に、そしてサブ要素paramapplication-descに(すでにapplet-descにあるように)追加されました。

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

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

JDK 9でのセキュリティ・アップデート

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にバンドルされなくなったツールおよびコンポーネントが示されています。

JDK 11で削除されているツールおよびコンポーネントの詳細は、「JDK 11で削除されたAPI」を参照してください。

削除されたネイティブ・ヘッダー生成ツール(javah)

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

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

javahのかわりに次を使用します
javac -h

JavaDBの削除

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

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

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

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

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

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

Java VisualVMの削除

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

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

native2asciiツールの削除

native2asciiツールはJDKから削除されました。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で削除されており、代替はありません。

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

次のステップ

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

  • 必要に応じて、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 移行ガイド,リリース11

F11787-03

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

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

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

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

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

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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。