はじめに
このガイドの目的は、既存のJavaアプリケーションをJDK 15に移行する際の潜在的な問題を識別できるようサポートし、移行の進め方について提案することです。また、JDK 15で行われた重要な変更および機能拡張についても説明します。
このガイドには、次のセクションがあります。
ノート:
- サポートされている最新のプラットフォームおよびオペレーティング・システムのバージョンは、Oracle JDKの動作保証済システム構成を確認してください。
- 移行プロセスを開始する前に、「削除されたAPI、ツールおよびコンポーネント」を参照してください。
JDKにおける重要な変更
アプリケーションを最新のJDKリリースに移行する前に、最新のJDKリリースと以前のJDKリリース間における更新内容および変更点について理解する必要があります。JDK 8から移行する場合は、JDK 8と後続リリースとの間の相違点(「JDK 8から後続のJDKリリースへの移行」を参照)についてよく理解しておくことも必要です。
最新のJDKリリースにおけるいくつかの重要な変更を確認するには、次の各項を参照してください。
JDK 15リリースにおける重要な変更
JDK 15の新機能および拡張機能の完全なリストは、JDK 15リリース・ノートを参照してください。
次に示すのは、Java SE 15およびJDK 15での更新内容の一部です。
- Java SE 13で最初にプレビューされたテキスト・ブロックは、このリリースで永続的な機能となり、プレビュー機能を有効にせずに使用できます。
テキスト・ブロックは、大部分のエスケープ・シーケンスの必要性を回避し、文字列を予測可能な方法で自動的に書式設定する複数行の文字列リテラルであり、必要に応じて開発者が書式を制御できます。『JEP 378: Text Blocks』および『テキスト・ブロック・プログラマーズ・ガイド』を参照してください。
- Zガベージ・コレクタ(ZGC)は本番で使用する準備ができ、実験的な機能ではなくなりました。ZGCを有効にするには、コマンドライン・オプション
-XX:+UseZGC
を使用します。『JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)』を参照してください。 - 非表示クラスは、他のクラスのバイトコードで直接使用できないクラスです。非表示クラスは、実行時にクラスを生成し、リフレクションを介して間接的に使用するフレームワークで使用することを目的としています。『JEP 371: Hidden Classes』を参照してください。
プレビューおよびインキュベータ機能
プレビュー機能の詳細は、Java言語のプレビュー機能を参照してください。
- シール・クラスは、Java言語のプレビュー機能です。シール・クラスおよびインタフェースは、それらを拡張または実装できる他のクラスまたはインタフェースを制限します。『JEP 360: Sealed Classes (Preview)』および『Java Platform, Standard Edition Java言語更新』のシール・クラスを参照してください。
- Java SE 14のプレビュー機能である
instanceof
のパターン一致は、このリリースで再プレビューされます。この機能を使用すると、プログラム内の共通ロジック(オブジェクトからのコンポーネントの条件付き抽出)をより簡潔かつ安全に表現できます。『JEP 375: Pattern Matching for instanceof (Second Preview)』および『Java Platform, Standard Edition Java言語更新』のパターン一致を参照してください。 - Java SE 14のプレビュー機能であるレコードは、このリリースで再プレビューされます。レコードは、不変データの透過的キャリアとして機能するクラスです。『JEP 384: Records (Second Preview)』および『Java Platform, Standard Edition Java言語更新』のレコード・クラスを参照してください。
- 外部メモリー・アクセスAPIを使用すると、JavaプログラムはJavaヒープ外の外部メモリーに効率的かつ安全にアクセスできます。『JEP 383: Foreign-Memory Access API (Second Incubator)』を参照してください。
JDK 14リリースにおける重要な変更
次に示すのは、Java SE 14およびJDK 14での変更点の一部です:
- switchは文または式として使用できるように拡張されたため、両方のフォームは、switch式から値を生成するための追加の新しい文とともに従来の
case ... :
ラベル(フォール・スルーあり)または新しいcase ... ->
ラベル(フォール・スルーなし)のいずれかを使用できます。『JEP 361: Switch Expressions (Standard)』および「Java言語の変更」を参照してください。 - G1は、不均一メモリー・アクセス(NUMA)メモリー・システムでの割当てパフォーマンスを向上させるために強化されています。『JEP 345: NUMA-Aware Memory Allocation for G1』を参照してください。
- JDKフライト・レコーダ・データが、連続したモニタリングを可能にするデータ・ストリームとして使用できるようになりました。『JEP 349: JFR Event Streaming』を参照してください。
- 新しいJDK固有のファイル・マッピング・モードが追加され、不揮発(NVM)メモリーを参照する
MappedByteBuffer
インスタンスをFileChannel
APIを使用して作成できるようになりました。『JEP 352: Non-Volatile Mapped Byte Buffers』を参照してください。 - 通貨の書式をロケール固有の会計書式で設定できます。たとえば、-$3.27ではなく($3.27)などです。『Accounting Currency Format Support』を参照してください。
- コンテナ環境など、現在のオペレーティング環境を基に値がレポートされるように、
com.sun.management.OperatingSystemMXBean
が拡張されました。オペレーティング・システムに関する情報を取得するツール用のMXBeanが、コンテナ環境で改善されています。『OperatingSystemMXBean made container aware』を参照してください。
実験的、プレビューおよびインキュベータ機能
Records
はJava言語のプレビュー機能であり、様々な不変データに対して透過的なホルダーであるクラスを宣言するためのコンパクトな構文を提供します。『JEP 359: Records (Preview)』を参照してください。instanceof
のパターン一致は、instanceof-and-cast
イディオムを簡略化するJavaの言語プレビュー機能です。『JEP 305: Pattern Matching for instanceof (Preview)』を参照してください。- テキスト・ブロックは、大部分のエスケープ・シーケンスの必要性を回避し、文字列を予測可能な方法で自動的に書式設定する複数行の文字列リテラルであり、必要に応じて開発者が書式を制御できます。テキスト・ブロックは、JDK 13でプレビュー機能として導入されました。JDK 14で、2つの新しいエスケープ・シーケンスを追加してテキスト・ブロックを再度プレビューしています。『JEP 368: Text Blocks (Second Preview)』を参照してください。
jpackage
は、自己完結型Javaアプリケーションをパッケージ化するための単純なツールです。『JEP 343: Packaging Tool (Incubator)』を参照してください。- Javaプログラムが、Javaヒープ外部の外部メモリーに効率的にアクセスできるようにするAPIが導入されました。『JEP 370: Foreign-Memory Access API (Incubator)』を参照してください。
- 以前はLinuxでのみ使用可能だったZガベージ・コレクタ(ZGC)は、WindowsとmacOSで実験的機能として導入されました。『JEP 364: ZGC on macOS』および『JEP 365: ZGC on Windows』を参照してください。
JDK 13リリースにおける重要な変更
次に示すのは、Java SE 13およびJDK 13での重要な拡張機能の一部です。
- 動的CDSアーカイブは、アプリケーション・クラスデータ共有(ApsCDS)を拡張します。これにより、Javaアプリケーションの終了時にクラスの動的アーカイブが可能になります。『JEP 350: Dynamic CDS Archives』を参照してください。
- テキスト・ブロックがJava言語に追加され、開発者が必要に応じてフォーマットを制御できるようになりました。これはプレビュー言語機能です。『JEP 355 Text Blocks (Preview)』および『JEP 12: Preview Language and VM Features』を参照してください。
switch
式、プレビュー言語機能は、文または式として使用できるように拡張されたため、両方のフォームで従来のラベル(フォール・スルーあり)または新しいラベル(フォール・スルーなし)のいずれかを使用できるようになりました。これは、switch
式から値を生成するための追加の新しい文とともに使用されます。『JEP 354: Switch Expressions (Preview)』および『JEP 12: Preview Language and VM Features』を参照してください。java.net.Socket
およびjava.net.ServerSocket
APIで使用される実装は、管理やデバッグが容易で、より単純な最新の実装に置き換えられました。『JEP 353: Reimplement the Legacy Socket API』を参照してください。- Unicode 12.1のサポート。Unicode 12.1に関する項を参照してください。
- ZGCは、未使用のヒープ・メモリーをオペレーティング・システムに戻すように拡張されており、アプリケーションのメモリー・フットプリントを拡張します。『JEP 351 ZGC Uncommit Unused Memory』を参照してください。
JDK 12リリースにおける重要な変更
次に示すのは、Java SE 12およびJDK 12での重要な追加および更新内容の一部です。
- JVM Constants APIが導入され、主要なクラス・ファイルおよびランタイム・アーティファクト、特に定数プールからロード可能な定数の名目的記述のモデル化に対応しています。JVM Constant APIに関する項を参照してください。
switch
文が拡張され、文または式として使用できるようになりました。これはプレビュー言語機能です。『JEP 325: Switch Expressions (Preview)』および『JEP 12: Preview Language and VM Features』を参照してください。- Unicode 11.0のサポート。Unicode 11.0に関する項を参照してください。
- 2019年5月から開始される日本の令和元号に対応する組文字のサポートが提供されました。組文字のサポートに関する項を参照してください。
NumberFormat
に、数値を簡潔な形式で書式設定するためのサポートが追加されました。簡潔な数値書式のサポートに関する項を参照してください。
JDK 11リリースにおける重要な変更
JDK 11にも、いくつかの重要な変更がありました。JDK 11は長期サポート(LTS)リリースであるため、JDK 11リリースにおける次の重要な変更を理解しておく必要があります。
-
JREおよびServer JREのダウンロードが提供されなくなったため、今後は自動更新を使用できません。
-
Java Web Start、JavaプラグインおよびJavaコントロール・パネルはJDKで提供されません。「デプロイメント・スタックの削除」を参照してください。
-
JavaFXはJDKで提供されなくなりました。現在は、https://openjfx.io/から個別のダウンロードとして入手できます。
-
JAXBおよびJAX-WSはJDKにバンドルされなくなりました。「Java EEおよびCORBAモジュールの削除」を参照してください。
セキュリティ・アップデート
この項では、JDKリリースでのセキュリティ・アップデートの詳細を示します。
JDK 15でのセキュリティ・アップデート
次に、JDK 15での重要なセキュリティ・アップデートを示します:
- 新しい署名スキームEdwards - Curve Digital Signature Algorithm (EdDSA)が実装されています。これは、JDKの既存の署名スキームと比較していくつかの利点を持つ最新の楕円曲線署名スキームです。この新しい署名スキームはECDSAを置き換えません。『JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)』を参照してください。
- SunJCEプロバイダは、SHA-3ベースのHmacアルゴリズムをサポートするようになりました。
- TLS署名スキームを構成するための新しいシステム・プロパティ
- certificate_authorities拡張機能のサポート
セキュリティ関連の変更の詳細は、リリース・ノートを参照してください。
JDK 11およびJDK 12のセキュリティ更新
JDK 11およびJDK 12では、次のセキュリティ・アップデートが行われました:
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 12では、次のルート証明書がキーストアから削除されました:
JDK 11では、次のルート証明書がトラストストアから削除されました:
削除された証明書を使用している製品は機能しなくなる可能性があります。これらの証明書が必要な場合は、無効になった証明書を使用してcacertsを構成し、移入する必要があります。トラストストアに証明書を追加するには、Java Development Kitツール仕様ガイドのkeytoolに関する項を参照してください。
JDK 9およびJDK 10のセキュリティ更新
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 Development Kitツール仕様のkeytoolに関する項を参照してください。
削除されたAPI
この項では、JDK 15、JDK 14、JDK 13、JDK 12およびJDK 11の各リリースで削除されたJava SE APIについて詳しく説明します。
jdeprscan --release 15 -l --for-removal
を実行して、JDK 15で削除対象としてマークされているAPIのリストを取得します。
ノート:
jdeprscanツールは、JDK 9以降で使用可能です。異なるJDKバージョンのAPIのリストを出力する場合は、リリース番号を9以上に置き換えます。Java SE 15で削除されたAPI
次のAPIはJava SE 15で削除されました。
フィールド
java.management.rmi.RMIConnectorServer.CREDENTIAL_TYPES
コンストラクタ
java.lang.invoke.ConstantBootstraps.<init>
java.lang.reflect.Modifier.<init>
Java SE 14で削除されたAPI
次のAPIはJava SE 14で削除されました。
java.security.acl
インタフェース
java.security.acl.Acl
java.security.acl.AclEntry
java.security.acl.Group
java.security.acl.Owner
java.security.acl.Permission
java.util.jar.Pack200.Packer
java.util.jar.Pack200.Unpacker
java.util.jar.Pack200
Java SE 13で削除されたAPI
java.lang.Runtime.traceInstructions(boolean)
java.lang.Runtime.traceMethodCalls(boolean)
Java SE 12で削除されたAPI
java.io.FileInputStream.finalize()
java.io.FileOutputStream.finalize()
java.util.zip.Deflater.finalize()
java.util.zip.Inflater.finalize()
java.util.zip.ZipFile.finalize()
JDK 11で削除されたAPI
JDK 11では、次のAPIが削除されました。これらのAPIの多くは以前のリリースで非推奨となり、新しいAPIで置き換えられています。
javax.security.auth.Policy
java.lang.Runtime.runFinalizersOnExit(boolean)
java.lang.SecurityManager.checkAwtEventQueueAccess()
java.lang.SecurityManager.checkMemberAccess(java.lang.Class,int)
java.lang.SecurityManager.checkSystemClipboardAccess()
java.lang.SecurityManager.checkTopLevelWindow(java.lang.Object)
java.lang.System.runFinalizersOnExit(boolean)
java.lang.Thread.destroy()
java.lang.Thread.stop(java.lang.Throwable)
JDK 10で削除されたAPI
JDK 10では、次の共通DOM APIが削除されました。
com.sun.java.browser.plugin2.DOM
sun.plugin.dom.DOMObject
JDK 9で削除されたAPI
JDK 10およびJDK 9リリースから削除された重要なAPIの一部を次に示します。
java.* APIの削除
Javaチームは下位互換性にコミットしています。アプリケーションがJDK 8で動作する場合、外部使用を意図したサポートされているAPIを使用しているかぎり、JDK 9以降のリリースでも動作します。
これには、次のものが含まれます。
- JCP標準、java.*、javax.*
- JDK固有のAPI、一部のcom.sun.*、一部のjdk.*
サポートされていたAPIがJDKから削除されることもありますが、必ず予告があります。コードが非推奨のAPIを使用しているかどうかを確認するには、静的分析ツールjdeprscanを実行します。
JDK 9で削除されたjava.* APIには、以前に非推奨となった、java.util.logging.LogManagerおよびjava.util.jar.Pack200パッケージの次のメソッドが含まれます。
java.util.logging.LogManager.addPropertyChangeListener
java.util.logging.LogManager.removePropertyChangeListener
java.util.jar.Pack200.Packer.addPropertyChangeListener
java.util.jar.Pack200.Packer.removePropertyChangeListener
java.util.jar.Pack200.Unpacker.addPropertyChangeListener
java.util.jar.Pack200.Unpacker.removePropertyChangeListener
sun.miscおよびsun.reflect APIからの削除および削除予定
java.* APIとは異なり、ほとんどすべてのsun.* APIはサポートされていないJDK内部APIであり、いつでもなくなる可能性があります。
一部のsun.* APIがJDK 9で削除されました。注意が必要な点として、sun.misc.BASE64Encoderおよびsun.misc.BASE64Decoderが削除されています。かわりに、JDK 8で追加された、サポートされているjava.util.Base64クラスを使用してください。
- sun.misc.Unsafe
このクラスの多くのメソッドの機能は変数ハンドルを使用することで実現できます。『JEP 193: Variable Handles』を参照してください。
- sun.reflect.Reflection::getCallerClass(int)
かわりにスタックウォーキングAPIを使用します。『JEP 259: Stack-Walking API』を参照してください。
java.awt.peerはアクセス不可
java.awt.peerおよびjava.awt.dnd.peerパッケージはJDK 9以降ではアクセスできません。このパッケージはjava.*ネームスペースにありますが、Java SE APIの一部であったことはありません。
これらのパッケージで定義されている型を参照するJava SE APIのすべてのメソッドが、JDK 9から削除されています。これらのパッケージで定義された型をこれまで受け付けたり返していたメソッドを呼び出すコードは、コンパイルや実行ができなくなりました。
- ピアがまだ設定されているかどうかを調べるには:
これをJDK 1.1 APIのComponent.isDisplayable()で置き換えてください。if (component.getPeer() != null) { .. }
public boolean isDisplayable() { return getPeer() != null;
- コンポーネントが軽量かどうかをテストするには:
これをJDK 1.2 APIのComponent.isLightweight()で置き換えてください。if (component.getPeer() instanceof LightweightPeer) ..
public boolean isLightweight() { return getPeer() instanceof LightweightPeer;
com.sun.image.codec.jpegパッケージの削除
非標準パッケージcom.sun.image.codec.jpegは削除されました。かわりにJava Image I/O APIを使用してください。
com.sun.image.codec.jpegパッケージは、JPEG形式のイメージ・ファイルのロードおよび保存を制御する非標準の方法としてJDK 1.2で追加されました。プラットフォーム仕様の一部となったことはありません。
JDK 1.4においてJava Image I/O APIが標準APIとして追加され、これはjavax.imageioパッケージにあります。これは選択されたイメージ形式のロードと保存を制御するための標準メカニズムを提供するもので、Java SE準拠のすべての実装においてJava Image I/O仕様に基づいてJPEGをサポートする必要があります。
コンパクト・プロファイルのツール・サポートの削除
JDK 9以降では、事前定義されたプロファイルに依存することなく、Javaランタイム・イメージ内のモジュールのサブセットに対してアプリケーションをビルドおよび実行できます。
SE 8で導入されたプロファイルは、Java SEプラットフォームAPIのサブセットを定義します。これにより、ストレージ容量が制限されているデバイス上でJavaランタイムの静的サイズを削減できます。JDK 8のツールでは、compact1
、compact2
およびcompact3
の3つのプロファイルをサポートしています。各プロファイルのAPI構成については、JDK 8のドキュメントの詳細なプロファイル構成およびAPIリファレンスに関する項を参照してください。
JDK 8では、javac
およびjava
コマンドを実行する際に-profile
オプションを使用してプロファイルを指定します。JDK 9以降では、-profile
オプションはjavac
において--release 8
オプションとの組合せでのみサポートされ、java
ではサポートされません。
JDK 9以降のリリースでは、コンパイルおよび実行時に使用されるモジュールを選択できます。新しい--limit-modules
オプションでモジュールを指定することで、コンパクト・プロファイル内にある同じAPIを取得できます。このオプションは、次の例に示すとおりjavac
コマンドとjava
コマンドの両方でサポートされています。
javac --limit-modules java.base,java.logging MyApp.java
java --limit-modules java.base,java.logging MyApp
-
compact1
プロファイル: java.base、java.logging、java.scripting -
compact2
プロファイル: java.base、java.logging、java.scripting、java.rmi、java.sql、java.xml -
compact3
プロファイル: java.basejava.logging、java.scripting、java.rmi、java.sql、java.xml、java.compiler、java.instrument、java.management、java.naming、java.prefs、java.security.jgss、java.security.sasl、java.sql.rowset、java.xml.crypto
jdeps
ツールを使用して、ソース・コードで使用されているJavaパッケージの静的分析を実行できます。これにより、アプリケーションを実行するのに必要なモジュールのセットがわかります。たとえばこれまでcompact3
プロファイルを使用していた場合、アプリケーションのビルド時にモジュールのセット全体を含める必要はないことが考えられます。Java Development Kitツール仕様のjdeps
に関する項を参照してください。
『JEP 200: The Modular JDK』を参照してください。
デフォルトでのCLDRロケール・データの使用
JDK 9以降ではUnicodeコンソーシアムの共通ロケール・データ・リポジトリ(CLDR)データがデフォルトのロケール・データとして有効化されており、特別に何かしなくても標準のロケール・データを使用できます。
JDK 8では、CLDRロケール・データはJREにバンドルされていましたが、デフォルトでは有効化されていませんでした。
日付、時間、数値書式といったロケール依存のサービスを使用するコードは、CLDRロケール・データにより異なる結果が生成されることがあります。System.out.printf()でさえロケールを認識します。
JDK 8互換の動作を有効にするには、システム・プロパティjava.locale.providers
の値で、CLDR
の前にCOMPAT
を設定します(例: java.locale.providers=COMPAT,CLDR
)。
『Java Platform, Standard Edition国際化ガイド』のデフォルトで有効化されるCLDRロケール・データに関する項および『JEP 252: Use CLDR Locale Data by Default』を参照してください。
削除されたツールとコンポーネント
次の項では、実験的、廃止、または不使用となり、JDKから削除されたツールやコンポーネントを示します。
JDK 15で削除および非推奨となったツールとコンポーネント
Nashorn JavaScriptエンジンの削除
Nashorn JavaScriptスクリプト・エンジンとAPI、およびjjs
ツールは、JDK 15で削除されました。エンジン、APIおよびツールは、Java 11での削除のために非推奨になりました。『JEP 372: Remove the Nashorn JavaScript Engine』を参照してください。
RMI静的スタブ・コンパイラ(rmic)ツールの削除
RMI静的スタブ・コンパイラ(rmic)ツールは削除されました。rmicツールは、JDK 13での削除のために非推奨になりました。サポートされているツールのセットからのrmicの削除を参照してください。
バイアス・ロックの無効化および非推奨
バイアス・ロックはデフォルトで無効になっており、関連するすべてのコマンドライン・オプションは非推奨になりました。『JEP 374: Disable and Deprecate Biased Locking』を参照してください。
削除のためのRMIアクティブ化の非推奨化
RMIアクティブ化メカニズムは非推奨になりました。プラットフォームの将来のバージョンで削除される可能性があります。『JEP 385: Deprecate RMI Activation for Removal』を参照してください。
JDK 14で削除された機能とコンポーネント
Concurrent Mark Sweep (CMS)ガベージ・コレクタの削除
CMSガベージ・コレクタが削除されました。『JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector』を参照してください。
Pack200ツールとAPIの削除
Pack200ツールおよびAPIはJDK 11で非推奨となり、JDK 14で削除されました。
pack200
およびunpack200
ツール、およびjava.util.jar.Pack200
パッケージのPack200
が削除されました。
JDK 13で削除されたツールとコンポーネント
javadoc
ツールからの旧機能の削除
Javadocツールから次の4つの機能が削除されました:
- HTML 4を使用したAPIドキュメントの生成のサポート
- 古いjavadoc APIのサポート
- HTMLフレームを使用したドキュメントの生成のサポート
--no-module-directories
オプションのサポート
削除されたjavadoc
機能の詳細は、JDK-8215608: 古いjavadoc機能の削除を参照してください。
JDK 11で削除されたツールとコンポーネント
デプロイメント・スタックの削除
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からダウンロードできます。ツールとコンポーネントの削除
主要ツール
appletviewer
JDK-8200146 : appletviewer起動ツールの削除を参照してください。
CORBAツール
idlj
orbd
servertool
tnamesrv
また、rmic
(RMIコンパイラ)で-idl
や-iiop
オプションがサポートされなくなりました。JDK 11リリース・ノートを参照してください。
Java Web Servicesツール
schemagen
wsgen
wsimport
xjc
Javaデプロイメント・ツール
javapackager
javaws
JDKからのJavaFXの削除に関する項を参照してください。
モニタリング・ツール
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 9およびJDK 10で削除されたツールとコンポーネント
このリストには、JDKにバンドルされなくなったツールおよびコンポーネントが示されています。
削除されたネイティブ・ヘッダー生成ツール(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
ツールを使用します。
CPUプロファイラ機能については、JDKにバンドルされているJava Flight Recorderを使用してください。
『JEP 240: Remove the JVM TI hprof Agent』を参照してください。
java-rmi.exeおよびjava-rmi.cgi起動ツールの削除
Windowsの起動ツールjava-rmi.exe
およびLinuxとSolarisの起動ツールjava-rmi.cgi
が削除されています。
java-rmi.cgi
はLinuxの$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プロパティ・ファイルに関する項を参照してください。
移行の準備
次の項は、アプリケーションの移行を成功させるのに役立ちます。
再コンパイルする前のプログラムの実行
最新のJDKリリース(JDK 15)でアプリケーションを実行します。たいていのコードおよびライブラリは変更しなくてもJDK 15上で動作するはずですが、一部のライブラリはアップグレードの必要があります。
ノート:
移行は反復的なプロセスです。プログラムをまず実行してみてから(このタスク)、これらの3つのタスクを平行して進めるのがおそらく最善でしょう:
アプリケーションの実行時に、廃止されたVMオプションに関するJVMからの警告がないか確認します。VMの起動に失敗する場合は、「削除されたGCオプション」を確認してください。
アプリケーションが正常に起動する場合は、慎重にテストして動作が使用中のJDKバージョンのときと同じであることを確認します。たとえば、一部の早期導入者は日付および通貨の形式が違っていることに気付いてきました。「デフォルトでのCLDRロケール・データの使用」を参照してください。
- JDK 15の新機能および変更点の詳細は、「JDK 15の新機能 - 新機能および機能拡張」を参照してください。
- JDK 14の新機能および変更点の詳細は、「JDK 14の新機能 - 新機能および機能拡張」を参照してください。
-
JDK 13の新機能および変更点の詳細は、「JDK 13の新機能 - 新機能および機能拡張」を参照してください。
-
JDK 12の新機能および変更点の詳細は、「JDK 12の新機能 - 新機能および機能拡張」を参照してください。
-
JDK 11の新機能および変更点の詳細は、「JDK 11の新機能 - 新機能および機能拡張」を参照してください。
-
JDK 10の新機能および変更点の詳細は、JDK 10の新機能を参照してください。
-
JDK 9の包括的な新機能一覧は、『JDK 9の新機能』を参照してください。
JDK 9での変更点の詳細は、JDK 9リリース・ノートを参照してください。
プログラムが正常に動作しているようであっても、このガイドの残りのステップを完了して問題のリストを確認するようにしてください。
サードパーティ・ライブラリの更新
使用するすべてのツールおよびサードパーティ・ライブラリについて、最新の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
のサポートされている値は15 (デフォルト)、14、13、12、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 Development Kitツール仕様の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 Development Kitツール仕様のjdeps
に関する項を参照してください。
jdeps
は静的分析ツールであり、コードの静的分析では依存性の完全なリストが得られない可能性があることに注意してください。コードでリフレクションを使用して内部APIが呼び出されている場合、jdeps
では警告は表示されません。
JDK 8から後続のJDKリリースへの移行
JDK 8と後続のJDKリリースとの間では、重要な変更が行われました。
新しいJava SEがリリースされると必ず、以前のリリースとのバイナリ、ソース、および動作上の非互換が発生します。JDK 9以降で発生したJava SEプラットフォームのモジュール化には多くのメリットがありましたが、同時に多くの変更も伴いました。公式のJava SEプラットフォームAPIおよびサポートされているJDK固有のAPIのみを使用するコードは、変更なしでそのまま動作します。JDK内部APIを使用するコードは引き続き動作しますが、サポート対象のAPIを使用するように移行する必要があります。
アクセス不可となった、削除された、またはデフォルト動作が変更されたAPIもあります。アプリケーションのコンパイルまたは実行時に問題が発生する可能性があります。削除されたツールとコンポーネントおよびセキュリティ・アップデートを参照してください。
次の各項では、JDK 8アプリケーションを後続のJDKリリースに移行する際に注意する必要があるJDKパッケージの変更点について説明します。
アプリケーションが最新バージョンの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
といった他のコマンドライン・オプションで有効になっているものを除き、すべてのリフレクション・アクセス操作が無効になります。これは将来のリリースにおいてデフォルト・モードになる予定です。
--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
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
が設定されたクラス・ローダーを作成するアプリケーションは、前述のように変更が必要となる可能性があります。
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 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』を参照してください。
削除された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
パッケージは削除されており、代替はありません。
Windowsレジストリ・キーの変更
Java 11以降のインストーラは、次のWindowsレジストリ・キーをJDKのインストール時に作成します。JDK 15の場合、インストーラによって次のWindowsレジストリ・キーが作成されます:
-
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK"
-
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\15"
JDKの2つのバージョンがインストールされている場合、2つの異なるWindowsレジストリ・キーが作成されます。たとえば、JDK 14.0.1をJDK 15とともにインストールする場合は、インストーラによって次のように別のWindowsレジストリ・キーが作成されます。
-
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK"
-
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\15"
-
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\14.0.1"
デプロイ
Javaデプロイメント・テクノロジはJDK 9で非推奨になり、JDK 11で削除されました。
事前インストールされたシステムJREに依存するのではなく、JDK 9で導入されたjlink
ツールを使用して、専用のランタイムをパッケージ化してデプロイしてください。
起動時のJREバージョン選択の削除
JDK 9以降では、起動時に起動されるJREとは異なるバージョンのJREを要求する機能は削除されています。
近年のアプリケーションは通常、Java Web Start (JNLP)、ネイティブOSパッケージ化システムまたはアクティブ・インストーラを使用してデプロイされます。これらのテクノロジは、必要なJREを必要に応じてダウンロードおよび更新する、必要となるJREを管理する独自の方法を備えています。そのため、起動ツールの起動時JREバージョン選択は非推奨となりました。
以前のリリースでは、アプリケーションの起動時にどのJREバージョン(またはバージョンの範囲)を使用するかを指定できました。バージョンの選択は、コマンドライン・オプションまたはアプリケーションのJARファイルのマニフェスト・エントリで可能でした。
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が次のように更新されました。
- JNLPファイルにおける
&
のかわりの&
の使用。JNLPファイル構文はXML仕様に準拠しており、すべてのJNLPファイルは標準のXMLパーサーによる解析が可能である必要があります。
JNLPファイルでは複雑な比較を指定できます。これまでこれはアンパサンド(
&
)を使用して行われていましたが、これは標準XMLではサポートされていません。&
を使用して複雑な比較を作成している場合、JNLPファイルで&
に置き換えてください。&
はすべてのバージョンのJNLPで互換性があります。 -
数値バージョン要素タイプと非数値バージョン要素タイプの比較。
これまで、
int
バージョンの要素とint
として解析できない他のバージョンの要素を比較する際は、両者をASCII値として辞書式に比較していました。JDK 9以降では、
int
として解析できる要素が他の要素より短い文字列である場合、ASCII値に基づいて辞書式に比較する前に先行のゼロが埋め込まれます。これにより循環がないことが保証されます。バージョン比較とJNLPサーブレットの両方が使用される場合、数値のみを使用してバージョンを表す必要があります。
java
(またはj2se
)要素にネストされたリソースがあるコンポーネント拡張機能。これは仕様で許可されています。以前もサポートされていましたが、このサポートが仕様に反映されていませんでした。
- FX XML拡張。
JNLP仕様が強化され、
type
属性がapplication-desc
要素に、そしてサブ要素param
がapplication-desc
に(すでにapplet-desc
にあるように)追加されました。JavaFXアプリケーションを指定する以前の方法も引き続きサポートされているため、これが既存のアプリケーションにおいて問題となることはありません。
JSR-056のJNLP仕様の更新に関する項を参照してください。
ガベージ・コレクションへの変更
この項では、JDK 9以降でガベージ・コレクションに加えられた変更について説明します。
デフォルトのガベージ・コレクタがG1に
ガベージファースト・ガベージ・コレクタ(G1 GC)は、JDK 9以降のリリースのデフォルトのガベージ・コレクタです。
大部分のユーザーにとって、G1 GCなどの一時停止の少ないコレクタは、JDK 8のデフォルトであったParallel GCなどのスループット指向のコレクタに比べて全体のパフォーマンスが優れています。
G1 GCのチューニングの詳細は、『Java Platform, Standard Edition HotSpot仮想マシン・ガベージ・コレクション・チューニング・ガイド』の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
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 Development Kitツール仕様のJVM Unified Logging Frameworkによるロギングの有効化に関する項および『JEP 271: Unified GC Logging』を参照してください。
ドキュメントのアクセシビリティについて
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 移行ガイド,リリース15
35314-01
2020年9月
Copyright © 2017, 2020, Oracle and/or its affiliates.
このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。
ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。
このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。
U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.The terms governing the U.S. Government’s use of Oracle cloud services are defined by the applicable contract for such services.No other rights are granted to the U.S. Government.
このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。
OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。
Intel、Intel Insideは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Epyc、AMDロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。
このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。