Oracle JDK 9移行ガイド
リリース9
E90930-02(原本部品番号:E82965-05)
2017年10月
このガイドの目的は、既存のJavaアプリケーションをJDK 9に移行する際の潜在的な問題を識別できるようサポートし、移行の進め方について提案することです。
新しいJava SEがリリースされると必ず、以前のリリースとのバイナリ、ソース、および動作上の非互換が発生します。Java SEプラットフォームのモジュール化には多くのメリットがありますが、同時に多くの変更も伴います。公式のJava SEプラットフォームAPIおよびサポートされているJDK固有のAPIのみを使用するコードは、変更なしでそのまま動作します。JDK内部APIを使用するコードは引き続き動作しますが、外部APIを使用するように移行する必要があります。
アプリケーションを移行するには、「移行の準備」にリストされている手順から開始します。
アプリケーションがJDK 9で正常に動作するようになったら、最後に、「今後のために」を確認してください。今後のリリースにおいて問題が発生するのを回避するのに役立ちます。
このガイドでは、コードをJDK 9で実行できるようにするのに必要となる変更について取り上げます。JDK 9のすべての新機能の包括的なリストについては、『Java Platform, Standard Edition JDK 9の新機能』を参照してください。このガイドで言及されている変更の詳細は、JDK 9リリース・ノートを参照してください。
アプリケーションをJDK 9で実行してみます。たいていのコードおよびライブラリは変更しなくてもJDK 9上で動作するはずですが、一部のライブラリはアップグレードの必要があります。
注意:
アプリケーションの実行時に、廃止されたVMオプションに関するJVMからの警告がないか確認します。VMの起動に失敗する場合は、削除されたオプションがないか探してください。JDK 8で非推奨となった一部のVMフラグがJDK 9で削除されているためです。「削除されたGCオプション」を参照してください。
アプリケーションが正常に起動する場合は、慎重にテストして動作がJDK 8のときと同じであることを確認します。たとえば、一部の早期導入者は日付および通貨の形式が違っていることに気付いてきました。「デフォルトでのCLDRロケール・データの使用」を参照してください。
プログラムが正常に動作しているようであっても、このガイドの残りの手順を完了して問題のリストを確認するようにしてください。
使用するすべてのツールおよびサードパーティ・ライブラリについて、JDK 9をサポートする更新版が必要となる可能性があります。
JDK 9で動作するように設計された各ライブラリまたはツールのバージョンについては、サードパーティ・ライブラリおよびツール・ベンダーのWebサイトを確認してください。提供されている場合は、その新しいバージョンをダウンロードおよびインストールしてください。
アプリケーションを構築するのにMavenまたはGradleを使用している場合、JDK 9をサポートしているさらに新しいバージョンにアップグレードしてください。
アプリケーションを開発するのにIDEを使用しているなら、既存のコードを移行するのに役立ちます。NetBeans、EclipseおよびIntelliJのIDEはいずれも、JDK 9サポートを含むバージョンが提供されています。
OpenJDK Wikiの品質支援に関する項で、多くのフリー・オープン・ソース・ソフトウェア(FOSS)プロジェクトをテストしたステータスを確認できます。
問題があることがわかっているAPIや機能にコードが依存している可能性があるため、JDK 9コンパイラでコードをコンパイルすると、将来のリリースへの移行が容易になります。ただし、必ず必要というわけではありません。
コードをJDK 9コンパイラでコンパイルする必要がある場合、次の点に注意してください。
ソース・コードでアンダスコア文字("_")を一文字で識別子として使用している場合、JDK 9ではそのコードはコンパイルできません。このように使用するとJDK 8では警告となり、JDK 9ではエラーとなります。
次に例を示します。
static Object _ = new Object();
このコードではコンパイラにより次のエラー・メッセージが生成されます。
MyClass.java:2: error: as of release 9, '_' is a keyword, and may not be used as a legal identifier.
javac
で-source
および-target
オプションを使用する場合、使用する値を確認してください。JDK 9において、javac
では-source
およ-target
オプションのサポートに"one plus three back" (3世代前まで)ポリシーが採用されています。
-source/-target
のサポートされている値は9 (デフォルト)、8、7および6です(6は非推奨で、この値が使用されると警告が表示されます)。
JDK 8では、-source
および-target
の値に1.5/5以前の値を指定するのは非推奨となり、警告が生成されました。JDK 9では、これらの値はエラーになります。
>javac -source 5 -target 5 Sample.java
warning: [options] bootstrap class path not set in conjunction with -source 1.5
error: Source option 1.5 is no longer supported. Use 1.6 or later.
error: Target option 1.5 is no longer supported. Use 1.6 or later.
できるだけ、-source
および-target
オプションのかわりに新しい--release
フラグを使用するようにしてください。--release N
フラグは概念としては次のマクロになります。
-source N -target N -bootclasspath $PATH_TO_rt.jar_FOR_RELEASE_N
--release
フラグの有効な引数には、-source
および-target
と同じく、"one plus three back"ポリシーが適用されます。
javac
は、JDK 1.0.2クラス・ファイルまでさかのぼる、以前のすべてのJDKのクラス・ファイルを認識および処理できます。
『JEP 182: Policy for Retiring javac -source and -target Options』を参照してください。
sun.misc.Unsafeなどの重要な内部JDK APIにはJDK 9でも引き続きアクセスできますが、JDKの大部分の内部APIにはコンパイル時にはアクセスできません。アプリケーションまたはそのライブラリが内部APIに依存していることを示すコンパイル・エラーが発生することがあります。
依存関係を特定するには、Java依存性分析ツールを実行します。「コードに対するjdepsの実行」を参照してください。可能であれば、サポートされている代替APIを使用するようにコードを更新してください。
JDK内部クラスへの参照があるソース・コードをコンパイルするための一時的な回避策として、--add-exports
オプションを使用できます。
以前より多くの非推奨メッセージが表示される可能性があります。削除の警告を伴う非推奨がある場合は、今後問題となるのを回避するためにそれらに対処する必要があります。
javac
に、Java SE 9の言語仕様に合わせていくつかの小さな変更が加えられました。
再コンパイル時にソース互換性の問題が発生する可能性があります。
JDK 9リリース・ノートには、JDK 9における、javac
コンパイラに加えられた変更およびソース互換性の問題の詳細が記載されています。
アプリケーションに対してjdeps
ツールを実行して、アプリケーションおよびライブラリが依存するパッケージおよびクラスを確認します。内部APIを使用している場合、jdeps
により、コードを更新する際に役立つ修正候補が表示されることがあります。
内部JDK APIの依存性を検出するには、jdeps
を-jdkinternals
オプションとともに実行します。たとえば、sun.misc.BASE64Encoder
を呼び出すクラスに対してjdeps
を実行すると、次のように表示されます。
>jdeps -jdkinternals Sample.class
Sample.class -> JDK removed internal API
Sample -> sun.misc.BASE64Encoder JDK internal API (JDK removed internal API)
Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependency on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
JDK Internal API Suggested Replacement
---------------- ---------------------
sun.misc.BASE64Encoder Use java.util.Base64 @since 1.8
Mavenを使用している場合、利用可能なjdeps
プラグインがあります。
jdeps
の構文については、Java Platform, Standard Editionツール・リファレンスのjdeps
に関する項を参照してください。
jdeps
は静的分析ツールであり、コードの静的分析によりすべてがわかるわけではありません。コードでリフレクションを使用して内部APIが呼び出されている場合、jdeps
では警告は表示されません。
JDK 9では新しいシンプルなバージョン文字列形式が導入されました。コードでメジャー、マイナー、セキュリティおよびパッチ更新を識別するのにバージョン文字列形式に依存している場合、更新が必要となる可能性があります。
新しいバージョン文字列の形式は次のとおりです。
$MAJOR.$MINOR.$SECURITY.$PATCH
たとえば、古いスキームでは、9u5
セキュリティ・リリースのバージョン文字列は1.9.0_5-b20
となります。
新しいスキームでは、同じリリースの短いバージョンは9.0.1
、長いバージョンは9.0.1+20
となります。
この変更は、java -versionと、java.runtime.version、java.vm.version、java.specification.versionおよびjava.vm.specification.versionといった関連システム・プロパティに影響します。
バージョン文字列を解析、検証および比較するための単純なJava APIが追加されました。java.lang.Runtime.Versionに関する項を参照してください。
『Java Platform, Standard Editionインストレーション・ガイド』のバージョン文字列の形式に関する項および『JEP 223: New Version-String Scheme』を参照してください。
一部のツールやライブラリでは、リフレクションを使用して内部使用のみを目的としたJDKの部分にアクセスします。この不正なリフレクション・アクセスはJDKの将来のリリースにおいて無効となる予定です。JDK 9においてこれはデフォルトで許可されており、警告が発行されます。
たとえば、Jython開始時に次のような警告が出力されたとします。
>java -jar jython-standalone-2.7.0.jar
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/C:/Jython/jython2.7.0/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD()
WARNING: Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11)
このような警告が表示された場合は、ツールまたはライブラリの保守担当者に連絡してください。警告の2行目は、JDKの内部部分にアクセスするためにコードでリフレクションが使用されている正確なJARファイルの名前を示しています。
デフォルトでは、java
起動ツールによって開始されたプロセスの存続期間中に発行されたリフレクション・アクセスに関する警告が最大1つ発行されます。警告の実際のタイミングは、リフレクション・アクセス操作を実行するツールおよびライブラリの動作によって異なります。この警告は、プロセスのライフタイムの早期に表示されることもあれば、起動後かなりたってから表示されることもあります。
この警告メッセージは、--add-opens
コマンドライン・フラグを使用してライブラリごとに無効にできます。たとえば、Jythonを次のようにして起動できます。
>java --add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED -jar jython-standalone-2.7.0.jar
Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11)
今回は、java
呼出しで明示的にリフレクション・アクセスが認識されるため、警告は発行されません。この例のように、クラス・パスのライブラリによって試行されるすべてのリフレクション・アクセス操作に対応するために、複数の--add-opens
フラグの指定が必要になる場合があります。
ツールおよびライブラリの動作についてさらに理解を深めるには、--illegal-access=warn
コマンドライン・フラグを使用できます。このフラグを使用すると、すべての不正なリフレクション・アクセス操作に対して警告メッセージが表示されます。さらに、--illegal-access=debug
を設定することで、スタック・トレースなどの、不正なリフレクション・アクセス操作に関する詳細情報を取得できます。
ライブラリを更新した場合やライブラリを入手した場合は、--illegal-access=deny
コマンドライン・フラグを使用して試してみることができます。これにより、--add-opens
といった他のコマンドライン・オプションで有効になっているものを除き、すべてのリフレクション・アクセス操作が無効になります。これは将来のリリースにおいてデフォルト・モードになる予定です。
--illegal-access=deny
と組み合せて使用して、警告を抑制できます。--add-exports
ランタイム・オプションを使用します。コンパイル時に--add-exports
を使用して内部APIにアクセスすることもできます。--add-opens
ランタイム・オプションを使用します。 すべてのリフレクション・アクセス警告を抑制する場合は、必要に応じて--add-exports
および--add-opens
オプションを使用します。
デフォルトでアクセスできないようになっている内部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も参照してください。
非publicメンバーにアクセスするためにクラス・パスにあるコードにディープ・リフレクションの実行を許可する必要がある場合は、--add-opens
ランタイム・オプションを使用します。
一部のライブラリはディープ・リフレクションを実行する(つまりsetAccessible(true)
となっている)ため、privateなメンバーを含め、すべてのメンバーにアクセスできます。このアクセス権は、java
コマンドラインで--add-opens
オプションを使用して付与できます。このオプションの使用により警告メッセージが生成されることはありません。
--illegal-access=deny
の場合、実行時にIllegalAccessException
またはInaccessibleObjectException
メッセージが表示され、例外メッセージに表示される情報に基づいて引数に--add-opens
ランタイム・オプションを使用できます。
--add-opens
オプションの構文は次のとおりです。 --add-opens module/package=target-module(,target-module)*このオプションでは、モジュール宣言にかかわらず、
<module>
で<package>
を<target-module>
に開くことを許可します。<target-module>
がALL-UNNAMED
の場合、ソース・パッケージが名前のないすべてのモジュールに、それが最初から存在するか後から作成されたかにかかわらずエクスポートされます。次に例を示します。--add-opens java.management/sun.management=ALL-UNNAMEDこの例では、クラス・パスにあるすべてのコードが
java.management/sun.management
パッケージのpublicタイプの非publicメンバーにアクセスできるようにします。注意:
たとえばJava Web StartのJNLPファイルなど、JNI呼出しAPIを使用している場合、--add-opens
とその値の間に等号を含める必要があります。<j2se version="9" java-vm-args="--add-opens=module/package=ALL-UNNAMED" />
コマンドラインでは等号はオプションです。
JDK 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が含まれています。
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
に簡略化されているために失敗する場合があります。
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE"
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE\9"
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE" "@CurrentVersion"=9
JDKがインストールされると、JDK
キーで前出の例のJRE
キーが置き換えられます。
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment"
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8"
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_144"
"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" "@CurrentVersion"=1.8
JDKがインストールされると、Java Development Kit
キーで前出の例のJava Runtime Environment
キーが置き換えられます。
JDKまたはJREの2つのバージョンがインストールされている場合で、一方がJDK 9で導入された新しいバージョン文字列形式を使用していて、もう一方が古いバージョン形式を使用している場合、Javaに関連した2つの異なるCurrentVersion
文字列がレジストリに存在します。一方がJDK 9より前でもっとも大きいバージョン番号を示し、もう一方がJDK 9以降でもっとも大きいバージョン番号を示します。
この項では、アクセス不可となった、削除された、またはデフォルト動作が変更されたAPIについて説明します。アプリケーションのコンパイルまたは実行時に、この項で説明されている問題が発生する可能性があります。
Javaチームは下位互換性にコミットしています。アプリケーションがJDK 8で動作する場合、外部使用を意図したサポートされているAPIを使用しているかぎり、JDK 9でも動作します。
これには、次のものが含まれます。
サポートされていた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が削除されています。かわりに、Java SE 8で追加された、サポートされているjava.util.Base64クラスを使用してください。
このクラスの多くのメソッドの機能は変数ハンドルを使用することで実現できます。『JEP 193: Variable Handles』を参照してください。
かわりにスタックウォーキングAPIを使用します。『JEP 259: Stack-Walking API』を参照してください。
java.awt.peerおよびjava.awt.dnd.peerパッケージはJDK 9ではアクセスできません。このパッケージはjava.*ネームスペースにありますが、Java SE APIの一部であったことはありません。
これらのパッケージで定義されている型を参照するJava SE APIのすべてのメソッドが、JDK 9から削除されています。これらのパッケージで定義された型をこれまで受け付けたり返していたメソッドを呼び出すコードは、コンパイルや実行ができなくなりました。
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は削除されました。かわりに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 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において、クラス・パスにあるコードをコンパイルまたは実行する際に、CORBAまたはJava SEとJava EE間で共有されるAPIを含むモジュールは、デフォルトでは解決されません。該当するものは次のとおりです。
これらのAPIのクラスへの参照を含む既存のコードは、ビルドを変更しなければコンパイルされません。同様に、これらのAPIのクラスへの参照があるクラス・パスのコードは、アプリケーションのデプロイ方法に変更を加えないかぎり、NoDefClassFoundError
またはClassNotFoundException
により失敗します。
これらのAPIのコードはJDK 9では削除されていませんが、モジュールは削除予定として非推奨となっています。これらのモジュールを解決しないというこのポリシーは、これらのAPIを今後のリリースのJava SEおよびJDKから削除するための最初の一歩です。
これらのAPIを使用するライブラリやアプリケーションの移行オプションは次のとおりです。
--add-modules
コマンドライン・オプションを使用して、APIを含むモジュールが起動時に解決されるようにします。たとえば、--add-module java.xml.bind
と指定すると、java.xml.bindモジュールが解決されます。これにより、JAXB APIを使用する既存のコードおよび実装がJDK 8の場合と同じように動作します。
これらのモジュールは最終的にはJDKから削除される予定のため、これは一時的な回避策です。
回避策として--add-modules java.se.ee
または--add-modules ALL-SYSTEM
を使用することは薦められていません。これらのオプションはすべてのJava EEモジュールを解決するものであり、これはスタンドアロン・バージョンのAPIも使用している環境において問題となります。
クラス・パスにあるスタンドアロン・バージョンのAPI(および必要に応じて実装)をデプロイしてください。各Java EE APIは、Maven Centralで公開されているプロジェクトによるスタンドアロンのテクノロジです。
アップグレード・モジュール・パスにこれらのモジュールのスタンドアロン・バージョンをデプロイします。スタンドアロン・バージョンはJava EEプロジェクトにより提供されています。
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 (Java Network Launch Protocol)が、不整合の解消、コードのメンテナンス性の向上、セキュリティの強化を目的として更新されました。
JNLPが次のように更新されました。
&
のかわりの&
の使用。JNLPファイル構文はXML仕様に準拠しており、すべてのJNLPファイルは標準のXMLパーサーによる解析が可能である必要があります。
JNLPファイルでは複雑な比較を指定できます。これまでこれはアンパサンド(&
)を使用して行われていましたが、これは標準XMLではサポートされていません。&
を使用して複雑な比較を作成している場合、JNLPファイルで&
に置き換えてください。&
はすべてのバージョンのJNLPで互換性があります。
数値バージョン要素タイプと非数値バージョン要素タイプの比較。
これまで、int
バージョンの要素とint
として解析できない他のバージョンの要素を比較する際は、両者をASCII値として辞書式に比較していました。
JDK 9では、int
として解析できる要素が他の要素より短い文字列である場合、ASCII値に基づいて辞書式に比較する前に先行のゼロが埋め込まれます。これにより循環がないことが保証されます。
バージョン比較とJNLPサーブレットの両方が使用される場合、数値のみを使用してバージョンを表す必要があります。
java
(またはj2se
)要素にネストされたリソースがあるコンポーネント拡張機能。これは仕様で許可されています。以前もサポートされていましたが、このサポートが仕様に反映されていませんでした。
JNLP仕様が強化され、type
属性がapplication-desc
要素に、そしてサブ要素param
がapplication-desc
に(すでにapplet-desc
にあるように)追加されました。
JavaFXアプリケーションを指定する以前の方法も引き続きサポートされているため、これが既存のアプリケーションにおいて問題となることはありません。
JSR-056のJNLP仕様の更新に関する項を参照してください。
アプリケーションでこれまでJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesが必要だった場合、これをダウンロードまたはインストールする必要はなくなりました。これらはJDKに含まれており、デフォルトで有効化されています。
ご使用の国または使用状況によりさらに制限の厳しいポリシーが必要な場合は、制限付きJava暗号化ポリシー・ファイルを引き続き使用できます。
デフォルトで提供されているいずれかのポリシー・ファイルで満たされていない要件がある場合は、これらのポリシー・ファイルを必要に合うようにカスタマイズできます。
<java-home/conf/security/java.security
ファイルのcrypto.policy
セキュリティ・プロパティまたはJava Platform, Standard Editionセキュリティ開発者ガイドの暗号化の強度の構成に関する項を参照してください。
実際の要件を決定する際は、輸出入管理コンサルタントまたは弁護士に相談することをお薦めします。
キーストアにはPKCS12形式を使用することをお薦めします。この形式はデフォルトのキーストア・タイプで、RSA PKCS12 Personal Information Exchange Syntax Standardに基づいています。
Java Platform, Standard Editionセキュリティ開発者ガイドのJSSEで使用するキーストアの作成に関する項、およびJava Platform, Standard Editionツール・リファレンスのkeytoolに関する項を参照してください。
ガベージファースト・ガベージ・コレクタ(G1 GC)は、JDK 9のデフォルトのガベージ・コレクタです。
大部分のユーザーにとって、G1 GCなどの一時停止の少ないコレクタは、JDK 8のデフォルトであったParallel GCなどのスループット指向のコレクタに比べて全体のパフォーマンスが優れています。
G1 GCのチューニングの詳細は、『Java Platform, Standard Edition Java仮想マシン・ガイド』のG1 GCのエルゴノミック・デフォルトに関する項およびチューニング可能なデフォルトに関する項を参照してください。
JDK 9では、次のGCの組合せの場合に、アプリケーションの起動に失敗します。
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)ロギングではJVM統合ロギング・フレームワークを使用しており、新しいログと古いログとでいくらかの違いがあります。現在使用しているGCログ・パーサーは変更がほぼ必要となります。
さらに、JVMロギング・オプションも更新が必要となる可能性があります。GC関連のすべてのロギングにおいて、通常は他のタグと組み合せて、gc
タグを(例: —Xlog:gc
)使用する必要があります。—XX:+PrintGCDetails
オプションおよび-XX:+PrintGC
オプションは非推奨となっています。
Java Platform, Standard Editionツール・リファレンスのJVM Unified Logging Frameworkによるロギングの有効化に関する項および『JEP 271: Unified GC Logging』を参照してください。
JavaDB (旧称Apache Derby)は、JDK 9には含まれていません。
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 -dump
。jmap
に関する項を参照してください。CPUプロファイラ機能については、JDKにバンドルされているJava Flight Recorderを使用してください。
注意:
Java Flight Recorderを本番で使用するには、商用ライセンスが必要です。商用機能の詳細とそれらを有効化する方法については、http://www.oracle.com/technetwork/java/javaseproducts/にアクセスしてください。『JEP 240: Remove the JVM TI hprof Agent』を参照してください。
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とオブジェクトのシリアライズに関する項を参照してください。
JDK 9において、JMX RMIコネクタからのIIOPトランスポートのサポートが、そのサポート・クラスとともに削除されました。
JDK 8では、IIOPトランスポートのサポートが必須からオプションにダウングレードされました。これは、JMX Remote APIからIIOPトランスポートのサポートを削除するための複数リリースにわたる取組みの最初のステップでした。JDK 9では、IIOPのサポートが完全に削除されました。
パブリックAPIの変更には次が含まれます。
javax.management.remote.rmi.RMIIIOPServerImpl
クラスは非推奨になりました。呼び出すと、そのすべてのメソッドおよびコンストラクタは、説明のメッセージとともにjava.lang.UnsupportedOperationException
をスローします。
2つのクラスorg.omg.stub.javax.management.rmi._RMIConnection_Stub
およびorg.omg.stub.javax.management.rmi._RMIConnection_Tie
は生成されません。
JDK 9では、Windows 32ビット・クライアントVMは使用できません。サーバーVMのみが提供されます。
JDK 8以前のリリースでは、Windows 32ビット・システム用にクライアントJVMとサーバーJVMの両方が提供されていました。JDK 9ではサーバーJVMのみが提供されます。サーバーJVMは、ピーク時の動作速度が最大となるように調整されています。
Java VisualVMは、Java仮想マシン上で実行されているコードについての情報を提供するツールです。jvisualvm
ツールはJDK 6、JDK 7およびJDK 8で提供されていました。
Java VisualVMはJDK 9にはバンドルされていません。JDK 9でVisualVMを使用する必要がある場合は、VisualVMオープン・ソース・プロジェクト・サイトから入手できます。
native2ascii
ツールはJDK 9で削除されました。JDK 9ではUTF-8ベースのプロパティ・リソース・バンドルがサポートされているため、UTF-8ベースのプロパティ・リソース・バンドルのISO-8859-1への変換ツールは必要なくなりました。
『Java Platform, Standard Edition国際化ガイド』のUTF-8プロパティ・ファイルに関する項を参照してください。
java.awt.Desktop
クラスには、Apple固有のcom.apple.eawt
およびcom.apple.eio
パッケージにあるAPIの代替が含まれています。新しいAPIはmacOS APIを置き換えるもので、プラットフォームに依存しません。
com.apple.eawt
およびcom.apple.eio
パッケージのAPIはカプセル化されているため、JDK 9でこれらに対してコンパイルすることはできません。ただし、実行時にはアクセス可能であるため、古いバージョンにコンパイルされた既存のコードは引き続き動作します。最終的には、apple
およびcom.apple
パッケージおよびそのサブパッケージの内部クラスを使用するライブラリやアプリケーションは新しいAPIへの移行が必要となります。
com.apple.concurrent
およびapple.applescript
パッケージは削除されており、代替はありません。
プラットフォーム固有のjavax.script実装であるAppleScriptエンジンはJDK 9で削除されており、代替はありません。
AppleScriptエンジンは、最近のリリースではほぼ使用できませんでした。JDK 7やJDK 8においてこの機能は、AppleバージョンのAppleScriptEngine.jar
ファイルがシステムにある場合にのみ動作していました。
アプリケーションがJDK 9で動作するようになったら、Java SEプラットフォームを最大限活用するためのいくつかの提案があります。
『Java Platform, Standard Edition JDK 9の新機能』をお読みになり、JDK 9の新機能について学習してください。
必要に応じて、javac
ツールで新しい–release
フラグを使用して、古いリリースのプラットフォームにクロス・コンパイルしてください。
コードを最新の機能により更新するには、IDEの提案を活用してください。
コードが非推奨のAPIを使用しているかどうかを確認するには、静的分析ツールjdeprscan
を実行します。このガイドで言及したとおり、APIがJDKから削除されることもありますが、必ず事前の予告があります。
マルチリリースJARファイル(jar
を参照)などの新機能に慣れ親しむようにしてください。
Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。
Oracleサポートへのアクセス
サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。
Java Platform, Standard Edition Oracle JDK 9移行ガイド,リリース9
E90930-02
Copyright © 2017, Oracle and/or its affiliates. All rights reserved.
このガイドは、アプリケーションをOracle JDK 9に移行するのに役立ちます。
このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。
ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。
このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。
OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。
Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。
このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。