デスクトップJavaの起動時間短縮を目指す新たなコンシューマJRE

今年のJavaOneでは、JavaFX の発表に加えて、2008 年中に公開が予定されているコンシューマ JRE について、Sun の Ethan Nicholas 氏、および Denis Gu 氏による講演が行われた(source)。『Filthy Rich Clients』の著者である Chet Haase 氏は、この件についてブログでさらに説明を加えている(source)。今回のコンシューマ JRE は、まだすべての詳細が明らかになっているわけではないが、Sun の焦点がデスクトップおよびエンドユーザーのエクスペリエンスに大きく動いたことを表しているのは明らかである。特に、JRE のWindows バージョンには多大な労力が注ぎ込まれている。

初回ダウンロードの問題を解決するため、今回のコンシューマ JRE の Windows バージョンには、当初 Java 7 に予定されていた Java カーネルが導入される。Java カーネルは、Java ランタイムの共通かつ必須である部分 (仮想マシン、ガーベッジコレクタ、およびクラスローダーなど) を読み込むことで機能するようになる。その後、特定のアプリケーションが指定する他の必要なダウンロードを行い、さらに、「class not found」が発生した場合にはそのクラスをダウンロードし、残りの JRE についてもリリース全体がシステムに存在するようになるまで並行してダウンロードする。これを実現するため、Sun では、Java ライブラリの編成方法にいくつかの変更を加える必要があった。rt.jar ファイルを大幅に小さくし、不足するクラスおよびライブラリを一般的なパッケージ境界に従ってコンポーネントに分割するようにした。結果として、アプリケーション開始前に行う必要のあるダウンロードのサイズは大幅に減少した。例えば、Limewire(サイト・英語) は 4MB 以下になっている。

Java ランタイムを構成する個々のファイルの物理的サイズが小さくなることにより、ディスクのシークタイムが短くなり、コールドスタートの時間が短縮される効果が期待できる。しかし、Sun では、コールドスタートが必要とされる回数を減らすという、より根本的な解決手段を考えている。Java のウォームスタートは、Java の一部が既にディスクキャッシュに存在しているため、それ程長い時間はかからない。一般的なアプリケーションであれば 2、3 秒で起動できる。しかし、コールドスタートは、OS が必要とするさまざまなデータを探すため、とても長い時間がかかることがある。場合によっては、非常に大きな Java ライブラリの中から探さなければならないこともある。こうした問題に対してよく行われる回避策としては、起動時に VM をメモリ上で開始しておくという方法がある （QuickTimeや Internet Explorer などのアプリケーションで行われている)。しかし、Java プログラムをまったく使用しない場合は RAM を無駄に消費していることになり、結果的には、Java をインストールするとマシンの動きが遅くなるという印象を生みかねない。Sun が Windows 向けコンシューマ JRE で実現しようとしている方法は、コア Java ファイルをディスクキャッシュに保持しようというものである。これは、該当ファイルに定期的にアクセスするバックグラウンドサービスを実行することによっ て実現する。これにより、Java アプリケーションの起動時間は、ウォームスタートの場合と同じ程度となる。このサービスは、マシン全体のパフォーマンスには最低限の影響しか及ぼさない。 システムメモリが不足してきた場合には、OS がディスクキャッシュを消去しメモリを再要求する (これとは対照的に、アプリケーションおよびデータが RAM 上にある場合、OS は再要求する前にページをディスクに書き込まなければならない)。制約の厳しいマシン上では、このサービスは自ら終了し、システムだけがそのまま機能できるようにする。

開発者が Java の適切なバージョンをユーザーのマシンに取得することができるように、Sun はいくつかの新しい JavaScript コマンドを導入している。これらのコマンドによって、開発者はどのバージョンの JRE がインストールされているかを判別し、必要であればユーザーに新しいバージョンを取得するように促すことができる。現在、次のようなコマンドが予定されている。

• getJREs() インストールされている JRE バージョンの一覧を返す。
• versionCheck(pattern) 指定したパターンが、インストールされている JRE に一致する場合に true を返す (例: “1.5*”、“1.6+”)
• installLatestJRE() 最新の JRE をブラウザまたは「プラットフォームに適切なメカニズム」を使用してインストールする。
• writeAppletTag(attributes, parameters) アプレットタグを手動で書き込むことを不要にする。
• runApplet(attributes, parameters, version)適切なバージョンの JRE がインストールされていることを確認し、アプレットタグを出力する。
• isWebStartInstalled() WebStartがインストールされているかどうかをチェックする。
• createWebStartLaunchButton(jnlpURL) クリックされたときに Webstart がインストールされているかを確認して、指定された JNLP を開始するボタンを出力する。

例えば、次のスクリプトは、JRE 1.5 以上がインストールされているかどうかをチェックする。インストールされている場合はアプレットを開始し、インストールされていない場合はユーザーにJRE をダウンロードするかどうかを確認する。

<script>
   deployJava.runApplet({code:"Applet.class", archive:"applet.jar",    width:320, height:240}, null, “1.5”); 
</script>

このスクリプトには、いくつかの制限がある。具体的には、このスクリプトでは、インストールされている JRE の最も新しいバージョンしか検出できない。またファミリーバージョンしか検出できない (つまり、1.5.0_11 ではなく、1.5 と検出される)。しかし、このようなスクリプトは、Sun がサポートするすべてのプラットフォームで使用可能になる予定である。Windows バージョンのコンシューマ JRE も、ネイティブコードを使用してこれらの関数を実行できるブラウザプラグインを含む予定であるので、今より正確な情報を得られるようになる。これは、開発者から見ればシームレスに処理される。JavaScript関数は、プラグインが使用可能であれば単純にそれに処理を委任する。

他にも、強化される点は多くある。新しい Swing クロスプラットフォームのルックアンドフィールである Nimbus も開発されている。これについては、InfoQ のこちらを参照して欲しい(記事)。Sun は、インストーラを完全に作成し直し、前のバージョンにあった重厚感を大幅に取り除いている。Swing FileChooser ではなく FileChooser を使用することができるように、ネイティブ FileChooserにアクセスする手段も提供される。Sun は、このコンシューマ JRE には新しいメディアコンポーネントも含まれる予定だとしている。ただし、現在のところ詳細は明らかになっていない。

原文はこちらです：http://www.infoq.com/news/2007/09/consumer-jre-jump