Loading article…
Javaアプレットとは、 Javaプログラミング言語、またはJavaバイトコードにコンパイルされる別のプログラミング言語で記述された小さなアプリケーションであり、Javaバイトコードの形式でユーザーに提供されます。
導入当初の想定用途は、ユーザーがウェブページからアプレットを起動し、ウェブブラウザ自体とは別のプロセスでJava仮想マシン（JVM）内でアプレットを実行することでした。Javaアプレットは、ウェブページのフレーム、新しいアプリケーションウィンドウ、Sun社のappletviewerと呼ばれるプログラム[ 6 ]、またはアプレットをテストするためのスタンドアロンツールに表示される可能性があります。
Java アプレットは、1995 年にリリースされた Java 言語の最初のバージョンで導入されました。2013 年以降、主要な Web ブラウザは、アプレットの実行に使用されていた基盤技術であるNPAPIのサポートを段階的に廃止し始め、2015 年から2017 年までにアプレットは完全に実行できなくなりました。Java アプレットは、2017 年に Java 9 で非推奨となり、 [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] 2021 年に Java 17 で削除のために非推奨となり、[ 12 ] 2026 年に Java 26 で削除されました。[ 13 ] [ 14 ]
Javaアプレットは通常Javaで書かれていましたが、 Jython、JRuby、Pascal、[ 15 ] Scala、NetRexx、Eiffel（SmartEiffel経由）などの他の言語も使用できました。
JavaScriptの初期バージョンとは異なり、Javaアプレットは3Dハードウェアアクセラレーションを利用できたため、複雑で計算負荷の高いビジュアライゼーションに適していました。アプレットの導入以来、JavaScriptはcanvasテクノロジー（特にWebGL、その後3Dグラフィックスの場合はWebGPU ） [ 16 ] [ 17 ]およびジャストインタイムコンパイル[ 18 ]を介してハードウェアアクセラレーショングラフィックスのサポートを獲得しました。
Javaバイトコードはクロスプラットフォーム（プラットフォーム非依存）であるため、JavaアプレットはMicrosoft Windows、FreeBSD、Unix、macOS、Linuxなど、多くのプラットフォームのクライアントで実行できます。ただし、標準のOracle JVMバイトコードの実行をサポートしていないモバイルデバイスでは実行できません。Androidデバイスでは、 Androidランタイム用にコンパイルされたJavaコードを実行できます。
アプレットは、HTMLだけでは実現できないインタラクティブな機能をWebアプリケーションに提供するために使用されます。マウス入力を取得できるだけでなく、ボタンやチェックボックスなどのコントロールも備えています。ユーザーの操作に応じて、アプレットは表示されるグラフィックコンテンツを変更することができます。そのため、アプレットはデモンストレーション、視覚化、教育に最適です。物理学から心臓生理学まで、さまざまな分野を学習するためのオンラインアプレット集が存在します。
アプレットはテキストエリアのみで構成される場合もあり、例えば、リモートシステムへのクロスプラットフォームのコマンドラインインターフェースを提供することができます。必要に応じて、アプレットは専用領域から離れて別のウィンドウとして実行することも可能です。ただし、アプレットは専用領域外のウェブページコンテンツを制御する能力がほとんどないため、他の種類のブラウザ拡張機能とは異なり、サイト全体の見た目を向上させるにはあまり役立ちません（ニュースティッカーやWYSIWYGエディタのようなアプレットも存在します）。また、アプレットはブラウザがネイティブでサポートしていない形式のメディアを再生することもできます。
HTMLで記述されたページには、アプレットに渡されるパラメータが埋め込まれている場合があります。そのため、渡されたパラメータによって、同じアプレットでも表示が異なる場合があります。
HTML5が登場する以前、最新のCSSとJavaScriptインターフェースDOMが標準となる以前からアプレットは利用可能だったため、マウスオーバーやナビゲーションボタンといった単純な効果にも広く使われていました。しかし、この方法はアクセシビリティに大きな問題を引き起こし、システムリソースを浪費していたため、現在では使われなくなっており、当時から強く推奨されていませんでした。
ほとんどのブラウザは、Javaアプレットをサンドボックス内で実行し、アプレットがファイルシステムなどのローカルデータにアクセスできないようにしていました。[ 19 ]アプレットのコードはWebサーバーからダウンロードされ、その後ブラウザはアプレットをWebページに埋め込むか、アプレットのユーザーインターフェイスを表示する新しいウィンドウを開きました。
最初の実装では、アプレットをクラスごとにダウンロードする方式が採用されていました。クラスは小さなファイルですが、その数が非常に多いため、アプレットは読み込みの遅いコンポーネントという評判を得ていました。しかし、.jarファイルが導入されて以来、アプレットは通常、画像ファイルと同程度のサイズ（数百キロバイトから数メガバイト）の単一ファイルとして配信されるようになりました。
Javaのシステムライブラリとランタイムは下位互換性があり、現在のバージョンと将来のバージョンのJava仮想マシンの両方で動作するコードを作成できます。
多くのJava開発者、ブログ、雑誌は、アプレットの代わりにJava Web Startテクノロジーを使用することを推奨しました。 [ 20 ] Java Web Startを使用すると、変更されていないアプレットコードを起動でき、それは別のウィンドウ（呼び出し元のブラウザー内ではない）で実行されます。
Javaサーブレットは、非公式にはサーバーサイドアプレットに「似ている」と表現されることがありますが、言語、機能、そしてここで説明するアプレットの特性のそれぞれにおいて異なります。
アプレットは、非推奨の HTML 要素 [ 21 ] または推奨の要素 [ 22 ] を使用して Web ページに表示されます。applet要素は、Mozillaファミリーobjectのブラウザで使用できます [ 23 ] (はHTML 4で非推奨になりましたが、HTML 5 に含まれています)。これは、アプレットのソースと場所を指定します。タグとタグの両方で、Java 仮想マシンをダウンロードしてインストールすることもできます (必要な場合)、または少なくともプラグイン ページに誘導できます。タグとタグは、特定の状態 (初期状態ではなく) で開始するシリアル化されたアプレットの読み込みもサポートしています。タグは、何らかの理由でブラウザがアプレットを実行できない場合に、アプレットの代わりに表示されるメッセージも指定します。embedembedobjectembedappletobject
しかし、object2010年に公式に推奨タグとなったにもかかわらず、このタグのサポートはobjectブラウザ間で一貫しておらず、Sunはappletマルチブラウザ環境での展開には古いタグを推奨し続けていました[ 24 ]。これは、最も人気のあるブラウザで一貫してサポートされている唯一のタグだったためです。複数のブラウザをサポートするには、objectタグを使用してアプレットを埋め込むには、JavaScript（ブラウザを認識してタグを調整する）、追加のブラウザ固有のタグの使用、またはサーバー側からの適応された出力の提供が必要になります。
Java ブラウザ プラグインはNPAPIに依存していましたが、NPAPI は古く、セキュリティ上の問題があるため、ほとんどすべての Web ブラウザ ベンダーがサポートを終了しているか、実装していません。2016 年 1 月、Oracle は JDK 9 に基づく Java ランタイム 環境ではブラウザ プラグインの提供を終了すると発表しました。[ 25 ]
Javaアプレットには、以下の利点のいずれか、またはすべてがある可能性があります。[ 26 ]
Javaアプレットは、他のクライアントサイドWeb技術と比較して、以下のような欠点があった。
サン・マイクロシステムズは、Javaのバージョン間の互換性を維持するために多大な努力を払い、必要に応じて法律によってJavaの移植性を強制してきた。オラクルも同様の戦略を継続しているようだ。
1997年の訴訟[ 28 ]は、MicrosoftがInternet Explorerに同梱された独自のJava仮想マシンを改変した後に提起されました。Microsoftはjava.awt、java.lang、java.ioパッケージ内のクラスに約50のメソッドと50のフィールド[ 28 ]を追加しました。その他の変更には、 RMI機能の削除と、 Java Native InterfaceをJNIから別の標準であるRNIに置き換えることが含まれていました。RMIはJava間の通信を容易にサポートし、Microsoft DCOMテクノロジーと競合するため削除されました。これらの変更に依存していた、または意図せず使用していたアプレットは、MicrosoftのJavaシステム内でのみ動作しました。Javaの要点は、独自の拡張機能があってはならず、コードはどこでも動作すべきであるという点であったため、Sunは商標権侵害で訴訟を起こしました。MicrosoftはSunに2000万ドルを支払うことに同意し、SunはMicrosoftにJavaを改変せずに使用できる限定ライセンスを期間限定で付与することに同意しました。[ 29 ]
Microsoft は、変更されていない独自の Java 仮想マシンを出荷し続けました。長年にわたり、それは非常に時代遅れになりましたが、Internet Explorer のデフォルトのままでした。後の調査では、この時期のアプレットには、Swingやその他の新しい機能を限定的に模倣した独自のクラスが含まれていることが多いことが明らかになりました。[ 30 ] 2002 年、Sun は独占禁止法違反訴訟を起こし、Microsoft の違法な独占の試みが Java プラットフォームに損害を与えたと主張しました。Sun は、Microsoft に対し、Sun の現在のバイナリ Java テクノロジー実装を Windows の一部として配布し、古い Microsoft デスクトップ オペレーティングシステムの推奨アップデートとして配布し、Microsoft の仮想マシンの配布を停止するよう要求しました (以前の訴訟で合意されたライセンス期間が満了したため)。[ 29 ] Microsoft は、係争中の独占禁止法問題に 7 億ドル、特許問題に 9 億ドル、将来 Sun のソフトウェアを使用するためのロイヤリティ料として 3 億 5000 万ドルを支払いました。[ 31 ]
セキュリティ モデルが大きく異なる 2 種類のアプレットがありました。署名付きアプレットと署名なしアプレットです。[ 32 ] Java SE 7 Update 21 (2013 年 4 月) 以降、アプレットと Web Start アプリケーションは信頼できる証明書で署名することが推奨され、署名なしアプレットを実行すると警告メッセージが表示されます。[ 33 ]さらに、Java 7 Update 51 以降、署名なしアプレットはデフォルトでブロックされました。Java コントロール パネルで例外を作成することで実行できます。[ 34 ]
署名されていないアプレットに対する制限は「厳しすぎる」と理解されていました。ローカルファイルシステムへのアクセスはできず、Webアクセスはアプレットのダウンロードサイトに限定されています。その他にも多くの重要な制限があります。たとえば、すべてのシステムプロパティにアクセスしたり、独自のクラスローダーを使用したり、マシンコードを呼び出したり、ローカルシステムで外部コマンドを実行したり、Javaリリースの一部として含まれるコアパッケージに属するクラスを再定義したりすることはできません。スタンドアロンフレームで実行することはできますが、そのようなフレームには、信頼できないアプレットであることを示すヘッダーが含まれています。禁止されているメソッドの最初の呼び出しが成功したとしても、アクセスコントローラが呼び出し元のコードのスタック全体をチェックして、呼び出しが不適切な場所から来ていないことを確認するため、自動的にセキュリティホールが発生するわけではありません。
他の複雑なシステムと同様に、Javaが最初にリリースされて以来、多くのセキュリティ上の問題が発見され、修正されてきました。これらの問題の中には（カレンダーのシリアル化に関するセキュリティバグのように）、長年にわたり誰にも気づかれずに放置されていたものもあれば、実際にマルウェアによって悪用されていることが発見されたものもあります。
一部の研究では、アプレットがブラウザをクラッシュさせたり、CPUリソースを過剰に消費したりすることが指摘されていますが、これらは迷惑行為とみなされ、真のセキュリティ上の欠陥とはみなされていません。しかし、署名されていないアプレットは、システムの他の部分における複数の深刻な設定エラーの組み合わせを悪用する複合攻撃に関与する可能性があります。署名されていないアプレットは、ホストされているサーバー上で直接実行する場合、コードベースによってサーバーとの通信は可能であっても、内部で実行されることでファイアウォールを回避できるため、より危険です。アプレットは、ホストされているサーバーに対してDoS攻撃を試みる可能性もありますが、通常、Webサイトを管理している人がアプレットも管理しているため、これは現実的ではありません。コミュニティは、ソースコードレビューや専用ドメインでのアプレット実行によって、この問題を解決できる可能性があります。
署名されていないアプレットは、発信元サーバーにホストされているマルウェアをダウンロードしようとすることもあります。しかし、そのようなファイルは一時的なデータであるため、一時フォルダに保存することしかできず、実行して攻撃を完了させる手段はありません。このようにしてアプレットを使ってPhoenixやSiberiaの脆弱性を拡散しようとする試みがありましたが、これらの脆弱性は内部的にJavaを使用しておらず、また他の様々な方法でも拡散されていました。
署名付きアプレット[ 35 ]には、ブラウザがリモートで実行されている独立した認証局サーバーを介して検証する必要のある署名が含まれています。この署名の生成には、専用ツールと認証局サーバーの管理者とのやり取りが必要です。署名が検証され、現在のマシンのユーザーも承認すると、署名付きアプレットはより多くの権限を取得し、通常のスタンドアロンプログラムと同等になります。その根拠は、アプレットの作成者が特定され、意図的な損害に対して責任を負うことになるからです。このアプローチにより、アプレットはクライアントサイドスクリプトでは不可能な多くのタスクに使用できます。ただし、このアプローチでは、ユーザーが誰を信頼するかを決定するなど、より多くの責任がユーザーに求められます。関連する懸念事項には、応答しない認証局サーバー、証明書発行時の署名者IDの誤った評価、既知のアプレット発行者がユーザーが承認しないようなことをしている可能性などがあります。したがって、Java 1.1以降に登場した署名付きアプレットは、実際にはより多くのセキュリティ上の懸念を抱えている可能性があります。
開発者自身が署名した自己署名アプレットは、セキュリティ上のリスクとなる可能性があります。Javaプラグインは、自己署名アプレットの認証を要求する際に警告を表示します。これは、アプレットの機能と安全性が開発者自身によってのみ保証されており、第三者による検証が行われていないためです。このような自己署名証明書は通常、リリース前の開発段階でのみ使用され、セキュリティに関する第三者による検証は重要ではありません。しかし、ほとんどのアプレット開発者は、ユーザーがアプレットの安全性を信頼できるよう、第三者による署名を求めます。
Javaのセキュリティ問題は、他のクライアントサイドスクリプトプラットフォームの同様の問題と根本的に異なるものではありません[ 36 ]。特に、署名付きアプレットに関連するすべての問題は、Microsoft ActiveXコンポーネントにも当てはまります。
2014年以降、自己署名および未署名のアプレットは、一般的に利用可能なJavaプラグインやJava Web Startでは受け入れられなくなりました。そのため、Javaアプレットをデプロイしたい開発者は、商用ソースから信頼できる証明書を取得する以外に選択肢がありません。
アプレットで可能だったことの全て、あるいはそれ以上を満たす代替技術（例えば、WebAssembly [ 37 ]やJavaScript）が存在する。JavaScriptはアプレットと同じページ内で共存でき、アプレットの起動（例えば、別のフレームで起動したり、プラットフォームの回避策を提供したりする）を支援し、後でアプレットコードから呼び出すことができる。JavaScriptの機能とパフォーマンスが向上するにつれて、アプレットのサポートと使用は減少し、最終的には廃止された。