Java Platform Standard Edition

• コンパイル時と実行時の中間である新しいオプション・フェーズとしてリンク時を導入します。このフェーズに、一連のモジュールをカスタム・ランタイム・イメージとしてアセンブおよび最適化することができます。Java Platform, Standard Editionツール・リファレンスのjlinkツールを参照してください。
• javac、jlinkおよびjavaツールにオプションを追加し、モジュールの定義を特定するモジュール・パスを指定できるようにします。
• モジュラJARファイル(module-info.classファイルを含むJARファイル)をそのルート・ディレクトリに導入します。
• JMOD形式を導入します。これはJARに似たパッケージング形式ですが、ネイティブ・コードと構成ファイルを含めることができる点が異なります。jmodツールを参照してください。

JDK自体は一連のモジュールに分割されています。この変更の特徴は次のとおりです。

• JDKのモジュールを組み合せて、次のような様々な構成にすることが可能になります。

  • JREおよびJDKに対応する構成。
  • Java SE 8で定義された各コンパクト・プロファイルと内容的にほぼ同等の構成。
  • 指定された一連のモジュールとそれらの必須モジュールのみを含むカスタム構成。

• JDKとJREのランタイム・イメージを再構成してモジュール対応にし、パフォーマンス、セキュリティおよび保守性を向上させます。

• ランタイム・イメージに格納されたモジュール、クラスおよびリソースについて、イメージの内部構造または形式を明らかにすることなく名前付けを行うための新しいURIスキームを定義します。

• 推奨標準のオーバーライド・メカニズムおよび拡張機能メカニズムを削除します。

• Javaランタイム・イメージから、rt.jarおよびtools.jarを削除します。

• デフォルトでほとんどのJDKの内部APIにアクセスできなくなりますが、少数の重要な、広く使用されている内部APIについては、その機能のすべてまたは大半をサポートする代替が出現するまでアクセスできます。

  jdeps -jdkinternalsコマンドを実行すると、内部JDK APIをコードで使用するかどうかを指定できます。

詳細は、次を参照してください。

• Java Platform Module System (JSR 376)

• JEP 261: モジュール・システム

• JEP 200: モジュラJDK

• JEP 220: モジュラ・ランタイム・イメージ

• JEP 260: ほとんどの内部APIのカプセル化

メジャー、マイナー、セキュリティおよびパッチの更新リリースを明確に区別できる、簡素化されたバージョン文字列の書式を提供します。

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

$MAJOR.$MINOR.$SECURITY.$PATCH

• $MAJORは、Java SEプラットフォーム仕様に記載されるような重要な新機能を含むメジャー・リリースの際に増分されるバージョン番号です(例: JDK 9)。メジャー・リリースには新機能および既存の機能に対する変更が含まれ、十分余裕を持って計画および発表されます。

• $MINORは、バグ修正、標準APIに対する変更、関連プラットフォーム仕様の範囲外の機能の実装など、マイナー更新ごとに増分されるバージョン番号です。

• $SECURITYは、重要な修正(セキュリティの改善に必要なものなど)を含むセキュリティ更新リリースの際に増分されるバージョン番号です。

• $PATCHは、セキュリティ修正や優先度の高い顧客向けの修正など、同時にテストされた修正を含むリリースの際に増分されるバージョン番号です。

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

Java Secure Socket Extension (JSSE) APIおよびSunJSSEセキュリティ・プロバイダがDTLSバージョン1.0およびDTLSバージョン1.2プロトコルをサポートできるようにします。

Java Platform, Standard Editionセキュリティ開発者ガイドのDatagram Transport Layer Security (DTLS)を参照してください。

JEP 244: TLS Application-Layer Protocol Negotiation拡張

トランスポート・レイヤー・セキュリティ(TLS)接続で使用するアプリケーション・プロトコルについて、クライアントとサーバーがネゴシエートできるようにします。Application-Layer Protocol Negotiation (ALPN)では、クライアントはサポートされているアプリケーション・プロトコルのリストをTLS ClientHelloメッセージの一部として送信します。サーバーはプロトコルを選択し、選択したプロトコルをTLS ServerHelloメッセージの一部として返します。アプリケーション・プロトコル・ネゴシエーションは、追加のネットワーク・ラウンドトリップなしで、TLSハンドシェイク内で行うことができます。

Java Platform, Standard Editionセキュリティ開発者ガイドのTLSハンドシェイクとApplication Layer Protocol Negotiationを参照してください。

TLS接続でサーバーがX.509証明書の失効をチェックできるようにします。サーバーは、問題の証明書についてOnline Certificate Status Protocol (OCSP)の応答側に問い合せることで、TLSハンドシェイク時にこれを行います。サーバーは、クライアントに返す証明書に失効情報を付加(つまり、「ステープリング」)し、クライアントが適切なアクションをとれるようにします。

クライアントは、TLSサーバーに対してOCSP staplingを要求できます。クライアントは、この機能をサポートするサーバーからのステープリング済の応答をチェックします。

Java Platform, Standard Editionセキュリティ開発者ガイドのOCSP Staplingを参照してください。

GHASH HotSpot組込みを使用して、AES/GCM/NoPaddingのパフォーマンスを34倍から150倍の範囲で改善します。GHASH組込みは、Intel x64 CPUのPCLMULQDQ命令およびSPARCのxmul/xmulhi命令によって加速されます。

RSA HotSpot組込みを使用して、BigInteger squareToLenおよびBigInteger mulAddメソッドのパフォーマンスを最大50%改善します。RSA組込みは、Intel x64のjava.math.BigIntegerクラスに適用されます。

特定のアルゴリズムのパフォーマンスを大幅に改善するプロバイダを構成できるよう、新しいセキュリティ・プロパティjdk.security.provider.preferredが導入されます。

Java Platform, Standard Editionセキュリティ開発者ガイドの特定のアルゴリズムに対する優先プロバイダの構成を参照してください。

SecureRandom APIのNIST SP 800-90Ar1に記載されているDeterministic Random Bit Generator (DRBG)メカニズムの機能を提供します。

DRBGメカニズムは、強度がSHA-512やAES-256と同等の最新のアルゴリズムを使用します。これらのメカニズムは、ユーザー要件にあわせて様々なセキュリティ強度および機能を使用して構成できます。

Java Platform, Standard Editionセキュリティ開発者ガイドの乱数の生成を参照してください。

より柔軟なメカニズムを提供して、SHA-1ベースの署名を使用するX.509証明書チェーンを無効にすることで、JDKのセキュリティ構成を改善します。

デフォルトでJDKに含まれる、ルートをアンカーとするTLSサーバー証明書チェーン内でSHA-1を無効にします。ローカルまたはエンタープライズ認証局(CA)は影響を受けません。

jdk.certpath.disabledAlgorithmsセキュリティ・プロパティは、無効化できる証明書のタイプをより効果的に制御できる、いくつかの新しい制約で強化されています。

JEP 288を参照してください。

デフォルトのキーストア・タイプをJKSからPKCS12に変更します。PKCS#12は、暗号鍵を格納するための、拡張性のある標準的な幅広くサポートされている形式です。PKCS12キーストアは、秘密鍵、信頼できる公開鍵証明書、および秘密鍵を格納することで、機密性を高めます。また、この機能は、PKCS12をサポートするMozilla、Microsoft Internet Explorer、OpenSSLなど、他のシステムとの相互運用性の機会を開きます。

SunJSSEプロバイダは、PKCS12ファイルの読取りおよび書込みのためのPKCS12 java.security.KeyStore形式の完全な実装を提供します。

Java Platform, Standard Editionセキュリティ開発者ガイドの鍵管理を参照してください。

PKCS12キーストアは、鍵と証明書を管理するユーティリティであるkeytoolで作成できます。

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

NIST FIPS 202に記載されているSHA-3暗号化ハッシュ機能をサポートします。

java.security.MessageDigest APIではこれ以外に、SHA3-224、SHA3-256、SHA3-384およびSHA3-512といった標準的なアルゴリズムがサポートされています。

次のプロバイダは、SHA-3アルゴリズムの拡張機能をサポートしています。

• SUNプロバイダ: SHA3-224、SHA3-256、SHA3-384およびSHA3-512

• OracleUcryptoプロバイダ: SHA-3ダイジェスト(Solaris 12.0でサポート)

OracleのJDK 9ビルドでは、Javaプラグインおよび関連アプレット・テクノロジが非推奨となります。これらのテクノロジは引き続きJDK 9で使用できますが、今後のリリースでは、Oracle JDKおよびJREからの削除対象とみなされます。

Webページに埋め込まれたアプレットおよびJavaFXアプリケーションを実行するにはJavaプラグインが必要です。これらのタイプのアプリケーションについては、Java Web Startまたは自己完結型のアプリケーションとして記述しなおすことを検討してください。

Java Platform, Standard Editionデプロイメント・ガイドのJava Web StartおよびJNLPへのJavaアプレットの移行および自己完結型アプリケーションのパッケージ化を参照してください。

Javaコントロール・パネル内のオプションのグループ化と表示を改善します。情報が見つけやすくなり、検索フィールドが用意され、モーダル・ダイアログ・ボックスは使用されなくなりました。旧バージョンのJavaコントロール・パネルから、いくつかのオプションの場所が変更されました。

Java Platform, Standard Editionデプロイメント・ガイドのJavaコントロール・パネルを参照してください。

モジュール認識やカスタム・ランタイム作成など、Project Jigsawの機能をJava Packagerに統合します。

小さめのパッケージを作成するには、jlinkツールを使用します。

JDK 9ランタイムのみを使用するアプリケーションを作成します。以前のリリースのJREでのアプリケーションのパッケージ化には使用できません。

Java Platform, Standard Editionデプロイメント・ガイドのJREのカスタマイズおよびモジュラ・アプリケーションのパッケージ化を参照してください。

アプレットAPIは非推奨となります。これは、Webブラウザ・ベンダーがJavaブラウザ・プラグインのサポートを削除したことにより有用性が下がっているためです。Appletクラスは引き続きJDK 9で使用できますが、今後のリリースでは削除対象とみなされます。Java Web Startまたは自己完結型のアプリケーションとしてアプレットを記述しなおすことを検討してください。

Java Platform, Standard Editionデプロイメント・ガイドのJava Web StartおよびJNLPへのJavaアプレットの移行および自己完結型アプリケーションのパッケージ化を参照してください。

いくつかの細かい変更を示します。

• privateインスタンス・メソッドで@SafeVargsを使用できます。

• 実質的にfinalの変数はtry-with-resources文でリソースとして使用できます。

• 型推論の引数型が表現可能な場合、匿名クラスでダイヤモンドを使用できます。

• Java SE 8から行われていた、正規の識別子名のセットからのアンダースコアの削除が完了しました。

• privateインタフェース・メソッドに対するサポートが追加されました。

Java Platform, Standard Edition Java言語更新のJava SE 9でのJava言語の変更を参照してください。

古いドックレットAPIを、別の標準的な既存のAPIを活用する、簡素化された新しいAPIに置き換えます。標準的なドックレットは、新しいドックレットAPIを使用するように書きなおされました。

HTML5出力の生成をサポートします。完全に準拠したHTML5出力を取得するには、ドキュメンテーション・コメント内に指定されたすべてのHTMLコンテンツがHTML5に準拠していることを確認してください。

生成されたAPIドキュメンテーションに検索ボックスが提供されます。この検索ボックスを使用して、プログラム要素、タグ内の単語、およびドキュメンテーション内のフレーズを検索できます。

モジュールの宣言でドキュメンテーション・コメントがサポートされます。新しいコマンドライン・オプションを使用すると、ドキュメント化する一連のモジュールを構成し、ドキュメント化されたすべてのモジュールの新しいサマリー・ページを生成することができます。

コンパイラ・ディレクティブ・オプションを使用してJVMのコンパイルを制御する方法を提供します。制御のレベルは、実行時に管理可能で、メソッドに固有です。コンパイラ・コントロールはCompileCommandを置き換えるもので、下位互換性を有しています。

Java Platform, Standard Edition Java仮想マシン・ガイドのコンパイラ・コントロールを参照してください。

コード・キャッシュを異なるセグメントに分割して(それぞれに特定のタイプのコンパイル済のコードが含まれます)、パフォーマンスを改善し、さらなる拡張を可能にします。

Java Platform, Standard Editionツール・リファレンスのjavaを参照してください。

プロパティの読取り、プロパティの書込み、関数の呼出しなど、実行時の高度なオブジェクト操作を適切なターゲット・メソッド・ハンドルに動的にリンクします。これらの操作は、渡された値の実際の型に基づいて、ターゲット・メソッド・ハンドルにリンクされます。これらのオブジェクト操作は、invokedynamicサイトとして表されます。

java.lang.invokeはinvokedynamicコール・サイトの動的リンクに対して低度のAPIを提供しますが、オブジェクトまたはそれらを実装するメソッドに対する、より高度な操作を表す方法は提供しません。

jdk.dynalinkパッケージでは、表現に動的型(静的に決定できない型)が含まれるプログラミング言語、およびこれらの動的型に対する操作がinvokedynamicコール・サイトとして表されるプログラミング言語(言語のオブジェクト・モデルまたは型システムがJVMのものと厳密に一致しないため)を実装できます。

ガベージファースト(G1)ガベージ・コレクタが強化され、いくつかの重要なメモリー再利用設定を自動的に決定できるようになります。これまでは、最善の結果を得るために、これらの設定を手動で設定する必要がありました。さらに、G1ガベージ・コレクタの操作性、決定論およびパフォーマンスに関する問題も修正されました。

JVMのすべてのコンポーネントに対する共通のロギング・システムが導入されます。

Java Platform, Standard Editionツール・リファレンスの-Xloggc javaオプションを参照してください。

JDK 8で非推奨となったガベージ・コレクタ(GC)の組合せが削除されます。

これは、次のGCの組合せがなくなることを意味します。

• DefNew + CMS

• ParNew + SerialOld

• インクリメンタルCMS

コンカレント・マーク・スイープ(CMS)の「フォアグラウンド」モードも削除されました。次のコマンドライン・フラグは削除されました。

• -Xincgc
• -XX:+CMSIncrementalMode
• -XX:+UseCMSCompactAtFullCollection
• -XX:+CMSFullGCsBeforeCompaction
• -XX:+UseCMSCollectionPassing

コマンドライン・フラグ-XX:+UseParNewGCに効果はなくなりました。ParNewの使用はCMSに限定され、CMSはParNewを必要とします。したがって、-XX:+UseParNewGCフラグは非推奨となっており、今後のリリースでは削除される可能性があります。

32ビットおよび64ビットのサーバー構成で、ガベージファースト(G1)がデフォルト・ガベージ・コレクタ(GC)になります。低停止時間のコレクタ(G1など)を使用すると、以前デフォルトであったスループット志向のコレクタ(パラレルGCなど)と比べて、ほとんどのユーザーにとって全体的なパフォーマンスが向上します。

JEP 158で導入された統合JVMロギング・フレームワークを使用して、ガベージ・コレクション(GC)ロギングが再実装されます。GCロギングは、現在のGCロギング形式との一貫性をとる形で再実装されます。ただし、新旧の形式にはいくつかの違いがあります。

Java Platform, Standard Editionツール・リファレンスのJVM統合ロギング・フレームワークによるロギングの有効化を参照してください。

コンカレント・マーク・スイープ(CMS)ガベージ・コレクタが非推奨となります。コマンドラインで-XX:+UseConcMarkSweepGCオプションを使用した要求には、警告メッセージが発行されます。ガベージファースト(G1)ガベージ・コレクタは、CMSのほとんどの使用を置き換えることを目的としています。

オペレーティング・システム・プロセスを制御および管理するためのAPIを改善します。

ProcessHandleクラスは、プロセスのネイティブ・プロセスID、引数、コマンド、起動時刻、累積CPU時間、ユーザー、親プロセスおよび子孫を提供します。このクラスは、プロセスの状態および終了プロセスをモニターすることもできます。ProcessHandle.onExitメソッドを使用すると、CompletableFutureクラスの非同期メカニズムはプロセスの終了時にアクションを実行できます。

Java Platform, Standard Edition Javaコア・ライブラリ開発者ガイドのプロセスAPI、java.lang.Processおよびjava.lang.ProcessHandleを参照してください。

オブジェクト・フィールドおよび配列要素に対するjava.util.concurrent.atomicおよびsun.misc.Unsafe操作に相当するものを呼び出す標準的な方法を定義します。

フェンス操作の標準的なセットを定義します。これには、メモリー・オーダリングのきめ細やかな制御を可能にするVarHandle静的メソッドが含まれます。これは、フェンス操作の非標準的なセットを提供するsun.misc.Unsafeに取って代わるものです。

参照されたオブジェクトが確実に到達可能な状態にとどまるよう、標準的な到達可能性フェンス操作を定義します。

文字列の内部表現にスペース効率の高い方法を採り入れます。これまで、Stringクラスは、1文字につき2バイト(16ビット)を使用して、文字をchar配列に格納していました。Stringクラスの新たな内部表現は、バイト配列にエンコーディング・フラグ・フィールドを加えたものです。

これは純粋に実装の変更であり、既存の公開インタフェースへの変更はありません。

Java Platform, Standard Editionツール・リファレンスでjavaコマンドのCompactStringsオプションを参照してください。

プラットフォーム・クラスがメッセージのロギングに使用できる最小限のAPIを、それらのメッセージの利用者に対するサービス・インタフェースとともに定義します。ライブラリまたはアプリケーションは、このサービスの実装を提供して、プラットフォーム・ログ・メッセージを任意のロギング・フレームワークにルーティングできます。実装が提供されない場合、java.util.logging APIに基づいてデフォルトの実装が使用されます。

JEP 155: 並行処理に関する更新についてJDK 8で導入された更新に対して、並行処理に関するさらなる更新が追加されます。これには、相互運用可能な公開と登録のフレームワークおよびCompletableFuture APIに対する拡張機能が含まれます。

Organization for the Advancement of Structured Information Standards (OASIS) XMLカタログ・バージョン1.1標準をサポートする標準的なXMLカタログAPIが追加されます。このAPIは、リゾルバを受け入れるJAXPプロセッサで組込みまたは外部のリゾルバとして使用できるカタログおよびカタログ・リゾルバの抽出を定義します。

内部カタログAPIを使用する既存のライブラリまたはアプリケーションを新しいAPIに移行して、新しい機能を利用する必要があります。

Java Platform, Standard Edition Javaコア・ライブラリ開発者ガイドのXMLカタログAPIを参照してください。

コレクションとマップのインスタンスを少ない要素で簡単に作成できるようになります。List、SetおよびMapインタフェースに対する新しい静的ファクトリ・メソッドは、それらのコレクションの不変インスタンスの作成を容易にします。

Set<String> alphabet = Set.of("a", "b", "c");

Java Platform, Standard Edition Javaコア・ライブラリ開発者ガイドの不変のリスト、セットおよびマップの作成を参照してください。APIのドキュメントについては、不変のSet静的ファクトリ・メソッド、不変のMap静的ファクトリ・メソッド、および不変のList静的ファクトリ・メソッドを参照してください。

java.lang.invokeパッケージのMethodHandle、MethodHandlesおよびMethodHandles.Lookupクラスが強化され、共通のユース・ケースが容易になり、より効果的にコンパイラを最適化できるようになります。

例: @Deprecated(since="9", forRemoval=true)

コア・プラットフォームの@Deprecated注釈が更新されました。

新しいツールjdeprscanを使用すると、非推奨となったJDK API要素の使用についてクラス・ライブラリ(JARファイル)をスキャンできます。

Java Platform, Standard Edition Javaコア・ライブラリ開発者ガイドの非推奨化に関する強化を参照してください。

Java Platform, Standard Editionツール・リファレンスのjdperscanを参照してください。

スピン・ループが実行中であることをJavaコードでヒントとして伝えることができるようにするAPIを定義します。スピン・ループは、ある条件が真であるか確認するため繰り返しチェックします。たとえば、ロックを取得できるタイミングをチェックし、取得後、なんらかの計算を安全に実行してから、ロックを解放します。このAPIは純粋にヒントであり、セマンティクス上の動作要件を伝えるものではありません。Thread.onSpinWaitメソッドを参照してください。

オブジェクト直列化データの受信ストリームをフィルタリングして、セキュリティと堅牢性を高めます。オブジェクト直列化クライアントは入力をより簡単に検証でき、エクスポートされたRemote Method Invocation (RMI)オブジェクトは呼出し引数をより簡単に検証できます。

直列化クライアントは、ObjectInputStreamに対して設定されるフィルタ・インタフェースを実装します。RMIの場合、オブジェクトはMarshalInputStreamに対してフィルタを設定して呼出し引数をアンマーシャル時に検証するRemoteServerRefを介してエクスポートされます。

スタック・トレース内の情報に対する簡単なフィルタリングと緩やかなアクセスを可能にするスタックウォーキングAPIを提供します。

このAPIは、指定の基準に一致するフレームで停止する短時間の走査と、スタック全体を走査する長時間の走査の両方をサポートします。指定の基準に一致するフレームで停止すると、呼出し側がスタックの最上位のフレームのみに関心があれば、すべてのフレームを検査するコストが回避されます。このAPIを使用すると、スタック・ウォーカの構成に応じて、Classオブジェクトにアクセスできるようになります。java.lang.Stackwalkerクラスを参照してください。

Xercesパーサの2.11.0バージョンをサポートするようにJDKが更新されます。公開JAXP APIに対する変更はありません。

この変更はXerces 2.11.0の次のカテゴリに関するものです。データ型、DOM L3 Serializer、XPointer、Catalog Resolver、およびXML Schema Validation (バグ修正は含まれますが、XML Schema 1.1開発コードは含まれません)。

特定のIDEおよびサーバー側フレームワークのアプリケーションがECMAScriptコードを解析および分析できるようにします。

文字列、URL、またはParserクラスのメソッドを含むファイルから、ECMAScriptコードを解析します。これらのメソッドは、ECMAScriptコードを抽象構文ツリーとして表すCompilationUnitTreeのインスタンスを返します。

jdk.nashorn.api.treeパッケージには、Nashorn Parser APIが含まれます。

• テンプレート文字列
• let、constおよびブロック・スコープ
• イテレータおよびfor..ofループ
• Map、Set、WeakMapおよびWeakSet
• シンボル
• 2進数と8進数のリテラル

解像度が異なる画像のセットを1つのマルチレゾリューション画像にカプセル化できるようにします。これは、実行時に概算で96dpiから300dpiに解像度が変動する可能性があるディスプレイ・デバイスにアプリケーションを適合させるために役立ちます。

java.awt.image.MultiResolutionImageインタフェースは、解像度が異なる画像のセットを1つのマルチレゾリューション画像にカプセル化します。これにより、アプリケーションで解像度が異なる画像を簡単に処理および表示できるようになります。

JavaFX UIコントロールおよびCSS機能のための公開APIが提供されます。これまで、これらを入手できるのは内部パッケージに限定されていましたが、モジュール化に伴いアクセスできなくなりました。

新しいパッケージjavafx.scene.control.skinには、各UIコントロールのスキン(外観)のデフォルトの実装を提供する、一連のクラスが含まれます。

新しいクラスCssParserは、Stylesheetオブジェクトを返すCSSパーサです。これにより、アプリケーションのCSSスタイリングをより効果的に制御できます。これはCSS API (javafx.cssパッケージ)の一部です。CSS APIには、新しいサポート・クラス(パーサによって使用される標準的なコンバータのセットなど)が含まれます。javafx.css.converterパッケージを参照してください。

@beaninfo Javadocタグを注釈型JavaBean、BeanPropertyおよびSwingContainerに置き換えます。

これらの注釈型は、実行時にBeanInfoを生成する際、対応する機能属性を設定します。したがって、Beanクラスごとに別々のBeanInfoクラスを作成するかわりに、Beanクラス内で直接、これらの属性を簡単に指定できます。また、自動生成されたクラスを削除できるため、クライアント・ライブラリのモジュール化も簡単になります。

Tag Image File Format (TIFF)の読取りと書込みを標準としてパッケージjavax.imageioに追加します。新しいパッケージjavax.imageio.plugins.tiffは、TIFFメタデータのオプションの操作を簡素化するクラスを提供します。

WindowsおよびLinuxでのHigh Dots Per Inch (HiDPI)ディスプレイで、AWTおよびSwingコンポーネントを自動的に拡大縮小およびサイズ設定します。

JDKは、すでにOS XでのHiDPI「Retinaディスプレイ」をサポートしています。

このリリースの前まで、WindowsおよびLinuxでは、従来のディスプレイの2倍から3倍の高さのピクセル密度を持つHiDPIディスプレイの場合でも、Javaアプリケーションはピクセルに基づいてサイズ設定およびレンダリングされていました。このため、読取りや使用の際にGUIコンポーネントとウィンドウが小さくなりすぎていました。

デスクトップの操作を可能にするjava.awt.Desktopクラスに次のようなメソッドが追加されます。

• カスタムの情報および設定ウィンドウの表示。

• ファイルのリストを開くか出力する要求の処理。

• URLを開く要求の処理。

• ネイティブ・ヘルプ・ビューア・アプリケーションを開く操作。

• デフォルト・メニュー・バーの設定。

• アプリケーションの強制終了の有効化または無効化。

これらの新しいメソッドは、OS Xパッケージcom.apple.eawtに含まれている内部APIの機能を置き換えます。JDK 9ではデフォルトでこれらのAPIにアクセスできません。com.apple.eioパッケージにはアクセスできなくなりました。

LinuxまたはSolarisで、Javaグラフィカル・アプリケーション(JavaFX、SwingまたはAbstract Window Toolkit (AWT)に基づくもの)がGTK+バージョン2またはバージョン3を使用できるようにします。

デフォルトでは、LinuxまたはSolarisのJDKは、使用可能であればGTK+ 2を使用し、使用不可の場合はGTK+ 3を使用します。

特定のバージョンのGTK+を使用するには、システム・プロパティjdk.gtk.versionを設定します。このシステム・プロパティの値は、2、2.2または3です。このプロパティは、アプリケーションがGTK+をロードする前に設定する必要があります。また、それ以前に別のツールキットによってロードされたGTK+バージョンと競合しないようにする必要があります。

Unicode 8.0をサポートします。JDK 8はUnicode 6.2をサポートしていました。

Unicode 6.3、7.0および8.0の標準をあわせると、10,555の文字、29のスクリプト、および42のブロックが導入されました。これらすべてがJDK 9でサポートされています。

共通ロケール・データ・リポジトリ(CLDR)のXMLベースのロケール・データ(JDK 8で初めて追加されました)をJDK 9のデフォルト・ロケール・データとして使用します。以前のリリースでは、デフォルトはJREでした。

JDK 8と互換性のある動作を有効にするには、システム・プロパティjava.locale.providersを値に設定し、CLDRの前にCOMPATを使用します。

Java Platform, Standard Edition国際化ガイドのデフォルトで使用可能となるCLDRロケール・データを参照してください。

プロパティ・ファイルをUTF-8エンコーディングでロードします。以前のリリースでは、プロパティ・リソース・バンドルをロードする際、ISO-8859-1エンコーディングが使用されていました。非ラテン文字を表す場合は、UTF-8のほうが利便性に優れています。

既存のプロパティ・ファイルのほとんどは影響を受けません。

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