従来の APPLET
タグの使用
このセクションでは、次のトピックについて説明します。
JavaTM Plug-in では、アプレットの起動用に HTML
APPLET タグをサポートしています。ユーザは APPLET タグを処理するために、Sun の JRE
がデフォルトの実行環境になるようブラウザを構成することができます。
説明
APPLET タグは、サポートされているオペレーティングシステムとブラウザで使用できます (「サ
ポートされているシステム構成」を参照)。ただし、Netscape 4.7x は Solaris でのみサポートされています。
- Java Plug-in では APPLET
タグがサポートされるようになりましたが、独自の技術を使用するアプレットはサポートされていません。こうした技術には以下のものがあります。
- CAB ファイル
- Authenticode 署名
- Java Moniker
- 従来のアプレット形式では、
object という名前の属性を PARAM
要素に使用すると、Sun VM で「Either "code" or "object" should be specified, but
not both.」という例外が発生します。Microsoft VM では、例外はスローされません。これは互換性の問題です。Sun VM
でこの例外を回避するには、アプレットで object という名前の属性を PARAM
要素に使用しないでください。
|
OBJECT タグとの互換性 (Windows プラットフォーム上の
Internet Explorer)
このリリースの Java Plug-in では、アプレットの起動用に APPLET
タグの使用をサポートしています。ただし、これまでの Java Plug-in との後方互換性も十分に確保されており、Windows
プラットフォーム上で稼動する Internet Explorer でアプレットを起動するための OBJECT
タグもサポートしています。開発者は以前と同じように、オプションで HTML コンバータを使用してアプレットの Web ページを設定し、OBJECT
タグを使用することができます。
OBJECT を使用して Java Plug-in 上でアプレットを起動する方法については、「Java Plug-in での OBJECT、EMBED、および APPLET タグの使用」
および 「HTML コンバータを使用した Java Plug-in 用
APPLET タグの変換」 を参照してください。
今回のリリースの Java Plug-in に関連した新しい Java Runtime Environment
では、従来のコンパイラで生成されたクラスファイルが実行されない場合があります。主に見られる症状は、こうしたクラスファイルをロードしようとしたとき
に仮想マシンが java.lang.ClassFormatError
をスローすることです。この失敗は、今回のリリースにおける変更とは特に関係ありません。これは、従来のバイトコードコンパイラがクラスファイルを生成す
るすべての状況において、適切なクラスファイル形式に厳密に準拠していなかったことが原因です。最近の仮想マシンは適切なクラスファイル形式に厳密に準拠
するよう実装されているので、不正な形式の古いクラスファイルをロードしようとするとエラーが発生します。古いクラスファイルに関する典型的な問題点は以
下のとおりです (ただしすべてを網羅したものではありません)。
- クラスファイルの最後に余分なバイトが存在する
- クラスファイルに、文字で始まらないメソッド名やフィールド名が含まれている
- クラスが別のクラスの private メンバにアクセスしようとする
- クラスファイルに、不正な定数プールインデックスや不正な UTF-8 文字列など、その他の形式エラーが存在する
- 以前の (サードパーティの)
バイトコードのオブファスケータによって、適切なクラスファイル形式に違反するクラスファイルが作成されている
この種類の問題は、現在の JDK にある Javac
バイトコードコンパイラを使用してクラスを再コンパイルすれば回避することができます。サードパーティのオブファスケータを使用する場合は、それが正しい
クラスファイル形式に準拠したクラスファイルを作成するかどうかを確認してください。
詳細については、『Java
配備ガイド』の「Java
アップグレードガイド」を参照してください。
上記で説明した APPLET タグのサポートに加えて、Java
Plug-in
はパフォーマンス面およびアーキテクチャ面で多くの拡張機能を備えており、通常は企業環境のように強力なクライアントプラットフォームを備えていない消費
者向けのクライアントマシンでも、広範に使用できるものになっています。これらの拡張機能の概要を以下に示します。
メモリ管理
- 動的な最大ヒープサイズが 128 MB から 96 MB に抑えられ、システム上で不要なページングが発生する問題を回避しています。
- クラスローダの実装が調整され、メモリがガベージコレクタによって以前より頻繁に再利用されるようになりました。
- 発生する可能性のあるメモリリークの問題は、この実装の JNI/COM スマートポインタを使用して対処します。
パフォーマンス
-
可能なかぎりブラウザのキャッシュに依存することにより、アプレットのダウンロード時間が大幅に短縮されました。本当に必要なとき以外、サーバ側では接続
が開かれません。
- アプレットのライフサイクルが非同期に制御されており、ページの切り替えが非常に高速に行えます。
- finalize() メソッドを削除することで、クラスローダオブジェクトの再生が高速になりました。
- バッファサイズが増えたので、HTTPS の読み込み速度が大幅に向上しました。
- 毎回動的な関数検索を行うのではなく、Microsoft の Wininet に静的にリンクすることにより、HTTPS
の呼び出しが非常に高速になりました。
- ネットワークを経由した BeanInfo 検索を廃止することで、JavaScript
のパフォーマンスが大幅に強化されました。
- Console Writer スレッドを使用して可能なかぎり System.out および System.err
のブロックを回避することで、Java コンソールのパフォーマンスが強化されました。
設計
- デフォルトの JavaScript と Java との対話が「スクリプト不可能」から「スクリプト可能」
に変更され、APPLET タグを通して実行されているアプレットはすべて、変更せずに JavaScript
で使用できるようになりました。
JDK 1.1 の互換性
- Java Plug-in によって sun.audio パッケージにアクセスできるようになりました。
- アプレットの中には、クラスファイル仕様に準拠した適切なクラスファイル形式を生成しないコンパイラによってコンパイルされたものが存在して
います。こうしたアプレットを Java Plug-in がロードしようとすると、ClassFormatError
が発生します。この問題に対処するために、PluginClassLoader
はバイトコードスキャナを提供しています。これによって不正なクラスファイルが即時に適合するようになり、アプレットが実行できるようになります。現時点
では、以下のエラーによる不正なクラスファイルだけが変換されます。
- ローカルの変数名に不正な定数プールインデックスが存在する
- クラスファイルの最後に余分なバイトが存在する
- コードセグメントの長さが誤っている
- 不正なフィールド/メソッド名
- 不正なフィールド/メソッド修飾子
- ローカル var テーブルにおける不正な start_pc/length
上記の「古いクラスファイルの更新」と、『Java 配備ガイド』の「Java
アップグレードガイド」も参照してください。