JDK 7 導入ガイド
JDK 7 のリリースとともに、Java 言語は進化を続けます。新しい言語機能によって、より厳密で堅牢なコードを記述することが可能になります。以前は実装が難しかった機能も、これからは簡単に実現できます。このガイドでは、JDK 6 から JDK 7 への移行を検討すべき理由について多少詳しく説明します。
このガイドのほかに、JDK 7 リリースへの移行の際に考慮すべきドキュメントが 2 つあります。
これらのページは JDK 7 リリースノートから参照できます。これらのドキュメントに記載されている情報は、ほとんどの部分で、このガイドとは重複していません。
このドキュメントでは、次の分野について説明します。
- Java 言語の拡張機能
- クラスローダー
- 並行性
- セキュリティー
- 入出力と NIO
- ネットワーク機能
- 国際化
- Swing および Java 2D の拡張機能
- JDBC の拡張機能
- Java DB の拡張機能
- Java XML テクノロジの拡張機能
- 配備の拡張機能
- Java 仮想マシン (JVM)
Java 言語の拡張機能
JDK 7 で導入された Java 言語の拡張機能のほとんどは、OpenJDK Project Coin によって支えられた JSR 334 の成果です。この取り組みの主な目標は、より堅牢ですっきりとしたコードを記述できるような言語の変更を取り入れることでした。
アプリケーションの開発に IDE を使用すれば、既存コードの移行に役立ちます。NetBeans、Eclipse、および IntelliJ IDE はどれも、Coin の機能をサポートしている出荷版です。
具体的な拡張機能の詳細を次のリストに示します。
文字列に対する switch 文の実行
JDK 7 より前は、switch を String オブジェクトに対して実行することはできませんでした。この機能を実現するには、if-then-else 文を使用する必要がありました。文字列に対して switch を実行する機能がサポートされるようになったため、if-then-else 文よりも効率的なバイトコードが生成されます。詳細は、「The switch Statement」(Java チュートリアル) および「switch 文内の文字列」(JDK 7 ガイド) を参照してください。
リークの可能性が少ないコードの記述
JDK 7 より前は、try 文 (try-catch-finally 文とも呼ばれる) で開かれたリソースはすべて、通常は finally ブロック内で手動で閉じる必要がありました。JDK 7 以降は、try-with-resources 文を使用すれば、try 文で宣言されたリソースはすべて確実に自動的に閉じられます。try 文で複数のリソース変数が宣言されている場合、それらは宣言されている順序とは逆の順序で閉じられます。詳細は、「try-with-resources 文」(JDK 7 ガイド) および「The try-with-resources Statement」(Java チュートリアル) を参照してください。
複数の例外のキャッチ
従来、複数の例外をキャッチする場合には、各例外に catch ブロックが 1 つ作成され、各ブロックにはその特定の例外の型を持つ変数が 1 つ含まれていました。多くの場合、これらの catch ブロックには、指定された例外変数を参照する同一のコードが含まれていました。この重複したコードを処理する共通のメソッドを記述することは、例外変数の型が異なっているため困難でした。
try {
Path fp = path.toRealPath(true);
} catch (NoSuchFileException x) {
System.err.format("%s: no such file or directory%n", path);
...
} catch (IOException x) {
System.err.format("%s%n", x);
...
}
JDK 7 以降は、| 記号を使用することにより、複数の例外を同じ catch ブロックでキャッチできます。
try {
Path fp = path.toRealPath(true);
} catch (NoSuchFileException | IOException x) {
System.err.format("%s: no such file or directory%n", path);
...
}
詳細は、「複数の例外型の処理」(JDK 7 ガイド) および「The catch Blocks」(Java チュートリアル) を参照してください。
より正確な例外の再スロー
JDK 7 より前は、catch ブロックでの例外の再スローは、try ブロックから実際にスロー可能な例外を示してはいませんでした。また、メソッドシグニチャーを変更しなければ、catch ブロックでスローされる例外の型を変更することもできませんでした。JDK 7 以降、例外のキャッチおよびスローのセマンティクスが洗練されています。ある型の例外をキャッチし、その例外変数に割り当てない場合は、try ブロックからスローされる可能性のあるチェック例外型がコンパイラによってコピーされます。これは、try ブロックから可能性のある例外をすべて再スローすることと同じです (ただし、例外変数を再割り当てしないことが前提)。たとえば、次のコードは JDK 7 では正当です。
JarFile retrieve(URL url) throws IOException {
Path temp = Files.createTempFile("jar_cache", null);
try (InputStream in = url.openStream()) {
Files.copy(in, temp, REPLACE_EXISTING);
return new JarFile(temp.toFile());
} catch (Throwable t) {
Files.delete(temp);
throw t;
}
}
この場合、Files.copy がスローできるのは IOException なので、それが唯一可能性のある例外型であることをコンパイラは認識します。詳細は、「型チェックがより包含的になった例外再スロー」(JDK 7 ガイド) を参照してください。
より簡潔な new 式のためのダイヤモンド構文
従来、new 式ではジェネリッククラスの型引数を指定する必要がありました。JDK 7 以降は、型引数をダイヤモンド表記 (<>) で置き換えることにより、自動型推定を利用できます。結果として得られるコードは、機能的には同じですが、より簡潔で読みやすくなります。詳細は、「Type Inference and Instantiation of Generic Classes」(Java チュートリアル) および「ジェネリックインスタンス作成のための型推定」(JDK 7 ガイド) を参照してください。
クラスローダー
マルチスレッドのクラスローディング
JDK 7 より前は、特定のタイプのカスタムクラスローダーにデッドロックが発生する可能性がありました。JDK 7 では、デッドロックを回避するようにロックメカニズムが変更されました。詳細は、「Java SE 7 のマルチスレッドのカスタムクラスローダー」(JDK 7 ガイド) を参照してください。
並行性
複数のプロセッサで分岐/結合フレームワークを使用する、よりスケーラブルなコード
JDK 7 リリースで導入された分岐/結合フレームワークは、ExecutorService インタフェースを使用し、作業を再帰的に分割することによって、複数のプロセッサをより効率的に利用できるようにします。詳細は、「Fork/Join」(Java チュートリアル) を参照してください。また、JDK ダウンロードバンドルの <Java_home>/sample/forkjoin ディレクトリには、分岐/結合フレームワークの例を示すサンプルが格納されています。
複数のスレッドから乱数を生成するための簡易クラス
java.util.concurrent.ThreadLocalRandom クラスが追加されたことにより、複数のスレッドまたは分岐/結合メカニズムから乱数を生成する必要のあるアプリケーションで、簡単に乱数を生成できるようになりました。
既存の乱数ジェネレータクラスを使用すると、知らない間にスレッド間の競合の原因となり、ベンチマーク結果が偏ってしまうことがよくあります。新しいメカニズムでは、競合が減少し、パフォーマンスが向上します。詳細は、「Concurrent Random Numbers」(Java チュートリアル) を参照してください。
セキュリティー
JDK 7 リリースには、多くの新しいセキュリティー拡張機能が組み込まれています。このような新機能のいくつかを次のリストに示します。
楕円曲線暗号 (ECC)
JDK 7 リリースには、ECC ベースの複数のアルゴリズム (ECDSA/ECDH) を提供する新しいネイティブプロバイダが追加されました。また、ECC プロバイダがあれば、ECC ベースの JSSE 暗号化方式群がすべてのプラットフォームで使用可能になります。以前は、ECC ベースの暗号化方式群を追加設定なしで使用できるのは、ネイティブな PKCS11 ECC 実装を備えたプラットフォーム (Solaris など) だけでした。詳細は、「Java 暗号化アーキテクチャー Oracle プロバイダのドキュメント」(JDK 7 ガイド) の SunEC プロバイダでサポートされるアルゴリズムに関するセクションを参照してください。
CertPath および TLS アルゴリズムの無効化
脆弱な暗号化アルゴリズムを無効化できるようになりました。JDK 7 リリースでは、証明書パス処理および TLS ハンドシェークで特定のアルゴリズムの使用を拒否するためのメカニズムが提供されています。たとえば、MD2 ダイジェストアルゴリズムは安全と見なされなくなっています。詳細は、「付録 D: 暗号化アルゴリズムの無効化」を参照してください。
TLS 1.1 のサポート
SunJSSE プロバイダは、RFC 4346 に記述されている TLS 1.1 をサポートするようになりました。もっとも重要な更新は、暗号ブロック連鎖 (CBC) 攻撃に対する保護です。
TLS 1.2 のサポート
SunJSSE プロバイダは、RFC 5246 に記述されている TLS 1.2 をサポートするようになりました。特に重要な点として、さまざまな内部ハッシングアルゴリズムを規定し、新しい暗号化方式群を追加し、柔軟性を (特に暗号化アルゴリズムのネゴシエーションについて) 高めています。
TLS の再ネゴシエーション
JDK 7 以降、Java SE では、TLS プロトコルの再ネゴシエーションの問題を解決する RFC 5746 がサポートされます。詳細は、「Transport Layer Security (TLS) 再ネゴシエーションの問題」(JDK 7 ガイド) を参照してください。
接続を考慮したトラスト管理
トラストマネージャーとキーマネージャーが、ハンドシェーク中に TLS 接続 (具体的には作成中の SSLSession) のパラメータを検査できるようになりました。たとえば、トラストマネージャーは、有効な署名アルゴリズムのリストに基づいて、使用される証明書の種類を制限できます。
EncryptedPreMasterSecret バージョン番号チェックの強化
JDK 7 リリースでは、TLS 1.1 および TLS 1.2 のハンドシェーク中のバージョン番号チェックが強化されています。詳細は、「JSSE リファレンスガイド」(JDK 7 ガイド) を参照してください。
JSSE クライアントの Server Name Indication (SNI)
JDK 7 リリースでは、JSSE クライアントでの Server Name Indication (SNI) 拡張がサポートされます。SNI は RFC 4366 に記述されており、TLS クライアントは SNI によって仮想サーバーに接続できます。
クライアントの SSLv2Hello をデフォルトで無効化
JDK 7 リリース以降では、クライアント上のデフォルトで有効なプロトコルのリストから SSLv2Hello が削除されています。
NTLM をサポート
クライアント側とサーバー側の両方で、NTLM 認証プロトコルが SASL メカニズムとしてサポートされるようになりました。実装されているのは認証レイヤーのみであり、通信のプライバシや統合は保護されません。
キータブファイルの使用
キータブファイルが変更されるたびに、Java によってこのファイルが読み取られるようになりました。このファイルを使用するアプリケーションが起動されるときに、このファイルが空白であっても、存在しなくてもかまいません。
JGSS のデフォルト構成ファイル
Windows システムや *nix システムに対して、デフォルトで krb5.conf が設定された JGSS 向けのデフォルト構成ファイルが提供されるようになりました。これにより、JGSS や krb5 のプログラム (特に Java アプレットの配備) が非常に簡単になります。
入出力と NIO
JDK 7 リリースでは、ファイル入出力メカニズムが完全に作り直されました。java.io.File クラスを基に構築された以前のメカニズムは引き続き使用可能ですが、java.nio.Path クラスおよび java.nio.Files クラスを基に構築された新しいメカニズムは、より堅牢なファイル入出力と、はるかに優れた機能を提供します。
現時点で NIO.2 ファイル入出力に移行できない場合でも新しい API を使用できるようにするために、JDK 7 では古い API からのブリッジが提供されています。Files.toPath メソッドの詳細、および旧バージョンに関するその他の考慮事項については、「Legacy File I/O Code」(Java チュートリアル) を参照してください。
次のリストでは、java.nio パッケージによって提供される向上した機能について紹介します。
より包括的なファイルメタデータのサポート
新しいファイル入出力メカニズムの一部として java.nio.file.attribute パッケージがあり、このパッケージはファイルメタデータを強力にサポートします。このパッケージには、ファイルアクセス権、ファイルの所有者、およびセキュリティー属性にアクセスするためのサポートが含まれています。ファイルのメタデータへのアクセスは効果的な方法で実装されています。独自のメタデータを定義したい場合は、UserDefinedFileAttributeView インタフェースを使用できます。詳細は、「Managing Metadata (File and File Store Attributes)」(Java チュートリアル) を参照してください。
シンボリックリンクのサポート
以前は、本当の意味でのシンボリックリンクのサポートは存在しませんでした。たとえば、ファイルツリーを再帰的にたどり、ファイルシステムに循環シンボリックリンクが含まれている場合には適切に対応する、信頼性の高いコードを記述することは以前は不可能でした。JDK 7 以降は、シンボリックリンクのサポートが組み込まれ、Path クラスと Files クラスは「リンク対応」になっています。ユーザーは、シンボリックリンクをどのように処理するか、また、循環リンクが存在する場合のエラーケースをどのように処理するかを決定します。詳細は、「Links, Symbolic or Otherwise」(Java チュートリアル) を参照してください。
スケーラブルなファイル入出力サポート
java.io.file のメソッドの多くはスケーラブルではありませんでした。サーバー上の大きなディレクトリのリストを要求すると、ハングアップが発生する可能性がありました。また、大きなディレクトリがメモリーリソースの問題を引き起こし、結果としてサービス拒否が発生することもありました。新しいファイル入出力パッケージは、ファイルシステムのサイズにかかわらず動作するように実装されています。
プラットフォーム間での動作の一貫性の向上
これまでは、プラットフォームによって動作の異なるメソッドがいくつかありました。たとえば、java.io.File.renameTo メソッドの動作は、プラットフォームによって異なっていました。新しい java.nio.Files ファイル入出力 API では、このような不整合が取り除かれています。
ファイルツリー走査のサポート
新しい FileVisitor API は、ファイルツリーを再帰的にたどるための、簡単に実装できるサポートを提供します。この機能により、ファイルシステム内のファイルやディレクトリを検査、変更、削除することができます。詳細は、「Walking the File Tree」(Java チュートリアル) を参照してください。
ファイルシステムの検索
PathMatcher API は、ファイルシステム上のファイルを検索するためのプログラムサポートを提供します。提供されている「glob」構文、正規表現、または独自に定義した照合コードを使用できます。詳細は、「Finding Files」(Java チュートリアル) を参照してください。
ディレクトリの変更の監視
監視サービス API により、ディレクトリを登録してファイルの変更通知を受け取ることができます。アプリケーションは、作成、削除、または変更イベントに登録できます。FileVisitor API を使用してこの機能を実装すると、ファイルツリー全体を再帰的に監視して変更を検出できます。詳細は、「Watching a Directory for Changes」(Java チュートリアル) を参照してください。
ネットワーク機能
JAR ファイルからロードされるライブラリの更新された実装のサポート
JDK 7 リリースより前は、jar ファイルが更新された場合に、最新のものがアプリケーションで使用されていることを確認することは困難でした。JDK 7 に新しく追加された URLClassLoader.close() メソッドは、JAR ファイルからロードされたクラスとリソースの更新された実装をサポートするという問題を解消します。詳細は、「URLClassLoader を閉じる」(JDK 7 ガイド) を参照してください。
Infiniband のサポート
新しい Sockets Direct Protocol (SDP) は、Infiniband ファブリックを介したスループットの高いストリーム接続をサポートします。SDP は Solaris と Linux でのみサポートされています。詳細は、「Understanding the Sockets Direct Protocol」(Java チュートリアル) を参照してください。
国際化
Unicode 6.0.0 を使用する機能
JDK 7 リリースは Unicode 6.0.0 標準をサポートしています。この標準では、10,000 を超える文字や、プロパティーとデータのファイルが追加でサポートされています。Java チュートリアルには、Unicode について説明する新しいセクションがあります。
ISO 4217 通貨コードの拡張サポート
通貨は、ISO 4217 コードで識別されます。JDK 7 リリースでは、JDK の新しいリリースを必要とせずに、新しい通貨に対応できます。詳細は、「ISO 4217 通貨コードの拡張サポート」(JDK 7 ガイド) を参照してください。
カテゴリロケールサポート
デフォルトロケールは、次の 2 種類の用途に対して別々に設定できます。フォーマット設定はリソースをフォーマットするために使用され、表示設定はメニューやダイアログで使用されます。これらのロケールタイプを個別に設定できるようにするプログラムサポート。Windows では、これらのデフォルト値はコントロールパネルの「標準と形式」および「表示言語」の設定に従って初期化されます。詳細は、「カテゴリロケールサポート」(JDK 7 ガイド) を参照してください。
更新された Locale のサポート
Locale クラスが更新されました。IETF BCP 47 (Tags for Identifying Languages) や UTS#35 (Unicode Locale Data Markup Language) といった業界標準のサポートが新たに追加されています。Locale.Builder 簡易クラスが追加され、Locale オブジェクトの作成がより簡単になりました。たとえば Linux プラットフォームや特定のリリースを指定するためなどに、ユーザー定義の拡張子をロケールに追加する機能。ほかの更新の詳細は、Java チュートリアルのレッスン「Creating a Locale」および「BCP 47 Extensions」を参照してください。
数字の形状決定の新しいサポート
Latin-1 の数字をほかの Unicode 10 進数に変換するために使用される NumericShaper クラスが拡張され、数字の形状決定がより簡単になりました。詳細は、「Converting Latin Digits to Other Unicode Digits」(Java チュートリアル) を参照してください。
正規表現 API での Unicode 6.0 サポート
JDK 7 リリースでは、正規表現のパターンマッチング機能が、Unicode 6.0 をサポートするように拡張されました。詳細は、「Unicode Support」(Java チュートリアル) を参照してください。
Swing および Java 2D の拡張機能
コンポーネントの描画方法およびイベントに対する応答方法を変更する機能
新しい JLayer クラスは、コンポーネントの外観および動作を変更するための強力なフレームワークを提供します。たとえば、JLayer クラス (および関連クラス) を使用して、動画化された待機インジケータをパネル上に作成できます。テキストフィールドに有効なデータが含まれている場合に、それを視覚的に示すこともできます。パネルの境界の外側で発生したすべてのマウスクリックを一時的に無視させることもできます。詳細は、「How to Decorate Components with JLayer」(Java チュートリアル) および「Using JLayer in Swing Applications」(YouTube ビデオ) を参照してください。
Swing の Look & Feel の更新
Nimbus と呼ばれる Swing の新しい Look & Feel は、com.sun.java.swing から標準 API 名前空間である javax.swing に移動しました。Nimbus Look & Feel は、デフォルトでは有効になっていません。詳細は、「Nimbus Look and Feel」(Java チュートリアル) を参照してください。
重量コンポーネントと軽量コンポーネントの混在
JDK 7 より前は、重量 (AWT) コンポーネントと軽量 (Swing) コンポーネントを同じコンテナ内で混在させることには問題がありました。JDK 7 以降では、これを簡単に実現できるようになりました。詳細は、「Mixing Heavyweight and Lightweight Components」(OTN の記事) を参照してください。
形状付きウィンドウと半透明ウィンドウの作成
JDK 7 リリースでは、透明度 (均一な透明度とピクセルごとの透明度の両方) を持つウィンドウや矩形以外のウィンドウの作成がサポートされます。詳細は、「How to Create Translucent and Shaped Windows」(Java チュートリアル) を参照してください。
2D レンダリングの向上
JDK 7 では、新しい XRender ベースの Java 2D レンダリングパイプラインが導入され、最新の X11 ベースのデスクトップに対して提供されています。グラフィックスのパフォーマンスを向上させるこのパイプラインは、デフォルトで無効になっていますが、コマンド行プロパティー -Dsun.java2d.xrender=true を使用して有効にできます。古い X11 構成では、XRender をサポートできないことがあります。詳細は、「Java 2D テクノロジのシステムプロパティー」(JDK 7 ガイド) を参照してください。
OpenType/CFF フォントのサポート
JDK 7 以降では、インストールされた OpenType/CFF フォントが GraphicsEnvironment.getAvailableFontFamilyNames などのメソッドを通じて列挙および表示されるようになりました。また、これらのフォントは Font.createFont メソッドによっても認識されます。
チベット語の書体のサポート
JDK 7 では、チベット語の書体のテキストレンダリングが新たにサポートされています。
Linux および Solaris 11 のフォントのサポート
従来、JDK の論理フォントは fontconfig.properties ファイルに静的に指定されていました。ただし、Linux のさまざまな実装では、フォントの有無に一貫性がありません。そのため、カスタムファイルがない場合は、アジア系言語 (CJK) のテキストなどがレンダリングされません。Linux および Solaris 11 の JDK 7 では、OS のバージョンに合わせてカスタマイズされた fontconfig.properties ファイルがない場合のデフォルトの動作として、システムの libfontconfig を使用して論理フォントに使用するフォントを選択します。この場合、同じプラットフォームライブラリを使用する Gnome/KDE デスクトップアプリケーションで使用されているフォントが、論理フォントに反映されます。詳細は、freedesktop.org の「Fontconfig」を参照してください。
HSL 色の選択の提供
JColorChooser クラスに HSV タブが追加されました。この機能により、HSL (色相-彩度-輝度) カラーモデルを使用してカラーを選択できます。この機能は JDK 7 では自動的に使用可能になります。
JDBC の拡張機能
JDBC 4.1 では、古いメソッドの動作が明確化され、java.sql および javax.sql インタフェースに新しいメソッドが導入されました。JDBC 4.1 の更新に関する詳細は、「JDBC 4.1」(JDK 7 ガイド) を参照してください。
RowSet 1.1
JDK 7 リリースでは、RowSetFactory インタフェースと RowSetProvider クラスの導入により、JDBC ドライバでサポートされるすべてのタイプの行セットを作成できます。詳細は、「Using JdbcRowSet Objects」(Java チュートリアル) を参照してください。
try-with-resources の使用
更新された JDBC パッケージでは、JDK 7 の try-with-resources 文を使用できます。Connection、ResultSet、および Statement タイプのリソースは、この文で使用された場合、自動的に閉じられるようになりました。try-with-resources の詳細は、「The try-with-resources Statement」(Java チュートリアル) を参照してください。
Java DB の拡張機能
JDK 7 にバンドルされている Java DB のバージョンには、JDK 6 にバンドルされているバージョンに比べ、多くの改善が加えられています。新機能には次のようなものがあります。
定義者の権利
プロシージャーと関数を、現在のユーザーの権限ではなく、その作成者の権限を使用して実行できるようになりました。
BOOLEAN データ型
BOOLEAN は、列、ルーチンの引数、および関数の戻り値として正当なデータ型になりました。
テーブルの切り詰め
新しい TRUNCATE TABLE コマンドは、テーブル内のすべての行をすばやく切り詰めます。
クエリー計画の表示
開発者は新しい PlanExporter ツールを利用して、クエリー計画をより効果的に表示できます。
Unicode のデータベース名
リモートクライアントは、ASCII コードセット以外の Unicode 文字を含むデータベース名を使用できるようになりました。
インデックス統計の自動計算
Java DB では統計が自動的にリフレッシュされるため、より適切なクエリー計画の選択に役立ちます。
中断処理の向上
接続スレッドの中断によって Java DB エンジンがクラッシュすることはなくなりました。
MAX の最適化
インデックス付きテーブルに対する MAX クエリーの実行が速くなる場合が増えます。
XML 演算子の移植性
xmlparse 演算子と xmlserialize 演算子が追加設定なしで動作するプラットフォームが増えました。
Java XML テクノロジの拡張機能
JDK 7 リリースの時点で、いくつかの XML テクノロジが Java SE プラットフォームに組み込まれており、それらのテクノロジのサポートされるバージョンが更新されました。
Java API for XML Processing (JAXP)
JDK 7 リリースは JAXP 1.4.5 をサポートするようになりました。前のバージョンの JAXP に比べ、多くのバグ修正といくつかの改善が行われています (特に準拠、セキュリティー、およびパフォーマンスの領域)。仕様は JAXP 1.4 のままですが、JSR 173 Maintenance Review 3 に従って、StAX は StAX 1.2 にアップグレードされています。詳細は、JAXP 1.4.5 リリースノートおよび JAXP 1.4.5 変更ログを参照してください。
Java Architecture for XML Binding (JAXB)
JDK 7 は JAXB 2.2.3 をサポートするようになりました。詳細は、JAXB RI 2.2 以降の JAXB 変更ログを参照してください。
Java API for XML Web Services (JAX-WS)
JDK 7 は JAX-WS 2.2.4 をサポートするようになりました。詳細は、JAX-WS RI 2.2 以降の JAX-WS 変更ログを参照してください。
配備の拡張機能
単一のネットワーク要求でアプレットをロードする機能
アプレットを含む Web ページをロードするには、少なくとも JNLP ファイルと jar ファイルをロードする必要があります。JDK 7 リリースでは、JNLP ファイルのコピーを HTML ページにキャッシュできるようになりました。これにより、アプレットの起動に必要なネットワーク要求の最小数が減り、アプレットの起動が速くなります。詳細は、「Embedding JNLP File in Applet Tag」(Java チュートリアル) を参照してください。
JavaScript からアプレットにアクセスしようとすると、アプレットが初期化されていない場合にブロックする可能性がある
ほとんどのブラウザはシングルスレッドの JavaScript エンジンを使用するため、アプレットの init メソッドが完了する前にアプレットにアクセスすると、ホストページとブラウザがフリーズしたように見えます。JDK 7 より前は、アプレットがアクセスを受け入れる準備ができているかどうかを簡単に確認する方法はありませんでした。JDK 7 では、アプレットの status プロパティーが導入されました。いつでもアプレットの status を確認して、アプレットが要求を受け入れる準備ができているかどうかを判定できます。または、コールバック関数を使用して、アプレットの準備ができたときに通知を受け取ることができます。この機能は isActive() API のブロックを軽減します。また、ステータスを提供する前にアプレットの init メソッドの完了を待つ必要はありません。この機能は、java_status_events パラメータを true に設定すると有効になります。詳細は、「Handling Initialization Status With Event Handlers」(Java チュートリアル) を参照してください。
Web Start の JNLP ファイル内のコードベースは配備ツールキットでは省略できる
JDK 7 より前は、JNLP アプリケーションを別の場所に移動するには、JNLP ファイル内の codebase 値を編集する必要がありました。jar ファイルに埋め込まれている署名付き JNLP ファイルの場合、これは特に複雑でした。JDK 7 以降、配備ツールキットの API を介して JNLP Web Start アプリケーションを配備する場合は、JNLP ファイル内の codebase の指定を省略できます。したがって、JNLP ファイルを新しい場所に移動する場合に、その新しい場所を埋め込むためにファイルを編集する必要はありません。詳細は、「Deploying Without Codebase」(Java チュートリアル) を参照してください。
JNLP ファイルに部分的に署名する機能
署名付き JNLP ファイルは、アプリケーションの起動記述子を外部から変更できないようにするために使用されます。JDK 7 より前は、署名付き JNLP ファイルと外部のブートストラップコピーが厳密に一致する必要がありました。そのため、アプリケーションを再配布することや、アプリケーションを再構築せずに配備を調整することは困難でした。現在では、開発者はテンプレートを使用して、外部 JNLP ファイルのどの部分が JAR ファイルに埋め込まれた JNLP ファイルと異なる可能性があるのかを定義できます。
リソースのターゲットとなる OS バージョンの限定
JDK 7 より前は、リソースのターゲットをオペレーティングシステムの特定の「ファミリ」に限定することが可能でした (os="linux" など)。この機能がきめ細かくなり、OS の特定のバージョンを指定できるようになりました。たとえば、os="Windows\ Vista Windows\ 7" と指定できます。詳細は、「JNLP ファイルの構文」(JDK 7 ガイド) の information 要素および resources 要素の os 属性を参照してください。
アプリケーションのインストール優先設定の定義
JDK 7 リリースでは、shortcut 要素に install 属性が追加されました。このオプション属性を使用して、「インストール済み」と見なされることに関するアプリケーションの優先設定を指定できます。Windows では、これによってアプリケーションが「プログラムの追加と削除」パネルに表示されるかどうかが決まります。詳細は、「JNLP ファイルの構文」(JDK 7 ガイド) を参照してください。
アプレットの装飾設定に対する制御の向上
JDK 7 リリースより前は、デスクトップショートカットから起動したアプレットは常に装飾され、同じアプレットをブラウザの外側にドラッグした場合は常に装飾なしになりました。JDK 7 以降は、この動作は JNLP ファイルで指定でき、ドラッグした場合とショートカットから起動した場合の両方で同じ設定が使用されます。デフォルトの動作は変更されていません。詳細は、「Requesting and Customizing Applet Decoration」(Java チュートリアル) を参照してください。
Java 仮想マシン (JVM)
Java 以外の言語に対する Java 仮想マシンのサポート
JDK 7 リリースでは、動的に型付けされたプログラミング言語を JVM に簡単に実装するために新しい JVM 命令が導入されています。詳細は、「Java 以外の言語に対する Java 仮想マシンのサポート」(JDK 7 ガイド) および「New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine」(OTN の記事) を参照してください。
ガベージファーストコレクタ
ガベージファーストコレクタは、JDK 7 でコンカレントマークスイープコレクタ (CMS) に代わる、サーバースタイルガベージコレクタです。詳細は、「ガベージファーストコレクタ」(JDK 7 ガイド) を参照してください。
Java HotSpot 仮想マシンのパフォーマンスの向上
JDK 7 リリースでは、階層型コンパイル、圧縮 OOP、エスケープ解析など、Java HotSpot のさまざまなパフォーマンス向上が加えられています。詳細は、「Java HotSpot 仮想マシンのパフォーマンスの向上」(JDK 7 ガイド) を参照してください。