Javaアプレット

Java アプレットは、 Javaプログラミング言語、またはJava バイトコードにコンパイルされる別のプログラミング言語で記述され、Javaバイトコードの形式でユーザーに配信される小さなアプリケーションです。

導入当時は、ユーザーがウェブページからアプレットを起動し、そのアプレットがウェブブラウザ自体とは別のプロセスでJava仮想マシン（JVM）内で実行されることが想定されていました。Javaアプレットは、ウェブページのフレーム、新しいアプリケーションウィンドウ、Sunのappletviewerと呼ばれるプログラム、^[6]、またはアプレットをテストするためのスタンドアロンツールに表示される可能性があります。^{[説明が必要]}

Javaアプレットは、1995年にリリースされたJava言語の最初のバージョンで導入されました。2013年以降、主要なウェブブラウザは、アプレットを実行するために使用されていた基盤技術であるNPAPIのサポートを段階的に廃止し始めました。2015年から2017年までにアプレットは完全に実行できなくなりました。Javaアプレットは、2017年にJava 9で非推奨になりました。 ^{[7] [8] [9] [10] [11]}

Javaアプレットは通常Javaで書かれていますが、 Jython、JRuby、Pascal、^[12] Scala、NetRexx、Eiffel （ SmartEiffel経由）などの他の言語も使用できます。

Java アプレットは非常に高速に実行され^{[引用が必要] 、2011 年までは}JavaScriptよりも何倍も高速でした。{{引用が必要|理由=真実であるという証拠がない主張があります。速度もここでは曖昧な用語です。起動時のオーバーヘッドが非常に大きかったことは間違いありません。|日付=2021 年 6 月} JavaScript とは異なり、Java アプレットは 3Dハードウェア アクセラレーションを利用できるため、計算量の多い複雑な視覚化に適しています。ブラウザがキャンバステクノロジ( 3D グラフィックスの場合は具体的にはWebGL ) ^{[13] [14]}やジャストインタイムでコンパイルされたJavaScript ^[15]によりハードウェア アクセラレーション グラフィックスのサポートを獲得するにつれて、速度の違いは目立たなくなりました。^{[引用が必要]}

Java バイトコードはクロスプラットフォーム（またはプラットフォームに依存しない）であるため、Java アプレットは、Microsoft Windows、FreeBSD、Unix、macOS、Linuxなど、多くのプラットフォームのクライアントで実行できます。標準の Oracle JVM バイトコードの実行をサポートしていないモバイル デバイスでは実行できません。Androidデバイスは、 Android Runtime用にコンパイルされた Java で記述されたコードを実行できます。

アプレットは、 HTMLだけでは提供できない対話型機能を Web アプリケーションに提供するために使用されます。マウス入力をキャプチャしたり、ボタンやチェック ボックスなどのコントロールを持つこともできます。ユーザーの操作に応じて、アプレットは提供されたグラフィック コンテンツを変更できます。このため、アプレットはデモンストレーション、視覚化、教育に適しています。物理学から心臓生理学まで、さまざまな科目を学習するためのオンライン アプレット コレクションがあります。

アプレットはテキスト領域のみになることもできます。たとえば、クロスプラットフォームのコマンドライン インターフェイスをリモート システムに提供します。必要に応じて、アプレットは専用領域を離れ、別のウィンドウとして実行できます。ただし、アプレットは、アプレット専用領域外の Web ページ コンテンツをほとんど制御できないため、他の種類のブラウザー拡張機能とは異なり、サイトの外観を改善するのにはあまり役立ちません (ニュース ティッカーやWYSIWYGエディターなどのアプレットも知られています)。アプレットは、ブラウザーでネイティブにサポートされていない形式のメディアを再生することもできます。

HTML でコーディングされたページには、アプレットに渡されるパラメータが埋め込まれている場合があります。このため、渡されたパラメータに応じて、同じアプレットの外観が異なる場合があります。

アプレットはHTML5、最新のCSSおよびJavaScriptインターフェイスDOMが標準になる前から利用可能であったため、マウスオーバーやナビゲーション ボタンなどの些細な効果にも広く使用されていました。アクセシビリティに大きな問題を引き起こし、システム リソースを誤用するこのアプローチは、現在では使用されておらず、当時でも強く推奨されていませんでした。

ほとんどのブラウザはJavaアプレットをサンドボックス内で実行し、アプレットがファイルシステムなどのローカルデータにアクセスできないようにしていました。^[16]アプレットのコードはWebサーバーからダウンロードされ、その後ブラウザはアプレットをWebページに埋め込むか、アプレットのユーザーインターフェイスを表示する新しいウィンドウを開きました。

最初の実装では、アプレットをクラスごとにダウンロードしていました。クラスは小さなファイルですが、多くの場合、数が多いため、アプレットは読み込みが遅いコンポーネントという評判でした。しかし、.jarファイルが導入されて以来、アプレットは通常、画像ファイルと同程度のサイズ (数百キロバイトから数メガバイト) の単一のファイルとして配信されるようになりました。

Javaシステム ライブラリとランタイムは下位互換性があり、現在のバージョンと将来のバージョンの Java 仮想マシンの両方で実行されるコードを記述できます。

多くのJava開発者、ブログ、雑誌は、アプレットの代わりにJava Web Startテクノロジを使用することを推奨しました。^[17] Java Web Startでは、変更されていないアプレットコードの起動が許可され、別のウィンドウ（呼び出し元のブラウザ内ではない）で実行されました。

Javaサーブレットは、非公式にはサーバー側アプレットに似ているとされることもありますが、言語、機能、およびここで説明するアプレットの各特性が異なります。

appletアプレットは、非推奨のHTML要素^[18]または推奨要素^[19]を使用してWebページに表示されますobject。要素は、Mozillaファミリーのブラウザで使用できます^[20] （はHTML 4では非推奨でしたが、HTML 5には含まれています）。 これは、アプレットのソースと場所を指定します。タグとタグはどちらも、Java仮想マシンをダウンロードしてインストールすることも（必要な場合）、少なくともプラグインページに誘導することもできます。タグとタグは、特定の（初期状態ではなく）状態で開始するシリアル化されたアプレットの読み込みもサポートしています。 タグは、ブラウザが何らかの理由でアプレットを実行できない場合に、アプレットの代わりに表示されるメッセージも指定します。 embedembedobjectembedappletobject

しかし、object2010年に正式に推奨されたタグであったにもかかわらず、タグのサポートはobjectブラウザ間でまだ一貫しておらず、Sunはappletマルチブラウザ環境での展開には古いタグを推奨し続けました。 ^[21]これは、最も人気のあるブラウザで一貫してサポートされている唯一のタグであったためです。複数のブラウザをサポートするには、objectタグを使用してアプレットを埋め込むには、JavaScript（ブラウザを認識してタグを調整する）、追加のブラウザ固有のタグの使用、またはサーバー側からの適応された出力の配信が必要になります。

JavaブラウザプラグインはNPAPIに依存していましたが、ほぼすべてのウェブブラウザベンダーは、その古さとセキュリティ上の問題のためにNPAPIのサポートを削除したか、実装していません。2016年1月、オラクルは、JDK 9に基づくJavaランタイム環境ではブラウザプラグインを廃止すると発表しました。^[22]

Javaアプレットには、次のような利点があります。^[23]

• FreeBSD、Linux、Microsoft Windows、macOS で動作するようにするのは簡単でした。つまり、クロスプラットフォームにすることです。アプレットは 21 世紀の最初の 10 年間はほとんどのWeb ブラウザーでサポートされていましたが、それ以降はほとんどのブラウザーがセキュリティ上の理由からアプレットのサポートを中止しました。
• 同じアプレットは、最新のプラグインバージョンだけでなく、インストールされているすべてのバージョンの Java で同時に動作します。ただし、アプレットがJava ランタイム環境(JRE) の新しいバージョンを必要とする場合、クライアントは大量のダウンロード中に待機する必要があります。
• ほとんどの Web ブラウザはアプレットをキャッシュするため、Web ページに戻ったときにアプレットがすぐに読み込まれます。アプレットは使用することでも改善されます。最初のアプレットが実行されると、JVM がすでに実行されており、後続のアプレットはすぐに起動します (ブラウザが新たに起動するたびに JVM を再起動する必要があります)。JRE バージョン 1.5 以降では、ブラウザがページ間を移動するとセキュリティ対策として JVM が再起動され、パフォーマンスの向上が失われました。
• 作業をサーバーからクライアントに移行し、ユーザー/クライアントの数に応じて Web ソリューションのスケーラビリティが向上しました。
• スタンドアロン プログラム ( Google Earthなど) が Web サーバーと通信する場合、そのサーバーは通常、クライアント ソフトウェアを最新の状態に保っていないユーザーのために、以前のすべてのバージョンをサポートする必要があります。対照的に、ブラウザーは最新のアプレット バージョンをロード (およびキャッシュ) するため、従来のバージョンをサポートする必要はありません。
• アプレットは、チェス盤上の図形の位置など、ユーザー状態の変更を自然にサポートしました。
• 開発者は、メイン ルーチン (アプレットのクラス内または別のクラス内) を作成し、アプレットで init() および start() を呼び出すだけで、アプレットを直接開発およびデバッグできるため、好みのJava SE開発環境で開発できます。必要なのは、AppletViewer プログラムまたは Web ブラウザでアプレットを再テストして、セキュリティ制限に準拠していることを確認することだけです。
• 信頼されていないアプレットはローカル マシンにアクセスできず、アプレットの送信元であるサーバーにのみアクセスできます。これにより、アプレットは、置き換えられるネイティブ実行可能ファイルよりも安全に実行できます。ただし、署名されたアプレットは、ユーザーが同意すれば、実行中のマシンに完全にアクセスできます。
• Java アプレットは高速で、ネイティブにインストールされたソフトウェアと同様のパフォーマンスを発揮しました。

Java アプレットには、他のクライアント側 Web テクノロジと比較して次のような欠点がありました。

• Java アプレットは、複雑で重いソフトウェア パッケージである Java Runtime Environment (JRE) に依存していました。また、通常はWeb ブラウザーのプラグインも必要でした。組織によっては、管理者によるソフトウェアのインストールのみを許可していました。その結果、管理者に連絡して JRE とプラグインのインストールを要求するほど重要なアプレットでない限り、ユーザーはアプレットを表示できませんでした。
• アプレットがシステムで使用可能な JRE よりも新しい JRE を必要とする場合、初めてアプレットを実行するユーザーは、大きな JRE のダウンロードが完了するまで待つ必要があります。
• iOSやAndroidのモバイルブラウザは、Javaアプレットをまったく実行しません。^[24]すべてのプラットフォームでアプレットが廃止される前から、デスクトップブラウザはモバイルオペレーティングシステムの台頭と同時にJavaアプレットのサポートを段階的に廃止していました。
• アプレットのコンテンツをスクリーン リーダーで利用できるようにするための標準がありませんでした。そのため、アプレットは特別なニーズを持つユーザーにとって Web サイトのアクセシビリティを損ないました。
• 他のクライアント側スクリプトと同様に、セキュリティ制限により、信頼されていないアプレットが目的を達成することが困難になったり、不可能になったりすることがあります。JAVA JRE インストールの java.policy ファイルを編集することによってのみ、ローカル ファイル システムやシステム クリップボード、またはブラウザにアプレットを提供するネットワーク ソース以外のネットワーク ソースへのアクセスを許可できます。
• ほとんどのユーザーは信頼できないアプレットと信頼できるアプレットの違いを気にしていなかったため、この区別はセキュリティにはあまり役立ちませんでした。この問題を解決するために、信頼できないアプレットを実行する機能は最終的に完全に削除され、その後すべてのアプレットが削除されました。

Sun は、 Java のバージョンが進化しても互換性が維持されるように多大な努力を払い、必要に応じて法律で Java の移植性を強制してきました。Oracle も同じ戦略を継続しているようです。

1997 年の訴訟^{[25]は、Microsoft が}独自の Java 仮想マシンを改良して作成し、Internet Explorer に同梱した後に提起された。Microsoft は、java.awt、java.lang、java.ioパッケージ内のクラスに約 50 個のメソッドと 50 個のフィールド^[25]を追加した。その他の改良には、 RMI機能の削除と、Java Native InterfaceをJNI から別の標準であるRNIに置き換えたことが含まれていた。RMI が削除されたのは、Java 間の通信のみを容易にサポートし、Microsoft DCOMテクノロジと競合するためである。これらの変更に依存していた、または単にうっかり使用していたアプレットは、Microsoft の Java システム内でのみ動作した。Sun は、Java の要点は独自の拡張機能があってはならず、コードはどこでも動作すべきであるという点にあったため、商標侵害で訴訟を起こした。Microsoft は Sun に 2,000 万ドルを支払うことに同意し、Sun は Microsoft に Java を改良なしで限られた期間のみ使用する限定的ライセンスを付与することに同意した。^[26]

マイクロソフトは、修正されていない独自の Java 仮想マシンを出荷し続けた。数年の間に、この仮想マシンは極めて時代遅れになったが、それでも Internet Explorer のデフォルトのままだった。後の調査で、この時代のアプレットには、Swingやその他の新しい機能を限定的に模倣した独自のクラスが含まれていることがわかった。^[27] 2002 年、サンは、マイクロソフトの違法な独占の試みが Java プラットフォームに損害を与えたとして、反トラスト訴訟を起こした。サンは、マイクロソフトに対し、サンの現在の Java テクノロジのバイナリ実装を Windows の一部として配布し、古いマイクロソフトのデスクトップ オペレーティング システムの推奨アップデートとして配布し、マイクロソフトの仮想マシンの配布を停止するよう要求した (以前の訴訟で合意されたライセンス期間が切れていたため)。^[26]マイクロソフトは、係争中の反トラスト問題に 7 億ドル、特許問題にさらに 9 億ドル、将来的にサンのソフトウェアを使用するために 3 億 5 千万ドルのロイヤルティ料を支払った。^{[28] [非一次ソースが必要]}

アプレットには、署名付きアプレットと署名なしアプレットという、セキュリティ モデルが大きく異なる 2 つのタイプがありました。^[29] Java SE 7 Update 21 (2013 年 4 月) 以降、アプレットと Web-Start アプリは信頼できる証明書で署名することが推奨され、署名なしアプレットを実行すると警告メッセージが表示されます。^[30]さらに、Java 7 Update 51 以降、署名なしアプレットはデフォルトでブロックされましたが、Java コントロール パネルで例外を作成することで実行できるようになりました。^[31]

署名のないアプレットに対する制限は「過酷」であると理解されていました。署名のないアプレットはローカル ファイル システムにアクセスできず、Web アクセスはアプレットのダウンロード サイトに限定されています。他にも重要な制限が多数あります。たとえば、すべてのシステム プロパティにアクセスしたり、独自のクラス ローダーを使用したり、ネイティブ コードを呼び出したり、ローカル システムで外部コマンドを実行したり、Java リリースの一部として含まれるコア パッケージに属するクラスを再定義したりすることはできません。スタンドアロン フレームで実行することはできますが、そのようなフレームには、信頼できないアプレットであることを示すヘッダーが含まれます。禁止されたメソッドの最初の呼び出しが成功しても、自動的にセキュリティ ホールが作成されるわけではありません。アクセス コントローラが呼び出しコードのスタック全体をチェックして、呼び出しが不適切な場所から行われていないことを確認するためです。

複雑なシステムの場合と同様、Java が最初にリリースされて以来、多くのセキュリティ問題が発見され、修正されてきました。これらの問題の一部 (カレンダーのシリアル化のセキュリティ バグなど) は、誰にも気づかれずに何年も放置されていました。その他の問題は、マルウェアによって使用されているのが発見されました。^[要出典]

一部の調査では、アプレットがブラウザをクラッシュさせたり、CPUリソースを過剰に使用したりすることが指摘されていますが、これらは迷惑行為として分類されており、真のセキュリティ上の欠陥とはされていません。ただし、署名されていないアプレットは、システムの他の部分にある複数の重大な構成エラーの組み合わせを悪用する複合攻撃に関与している可能性があります。また、署名されていないアプレットは、コード ベースによってサーバーと通信できますが、内部で実行するとファイアウォールをバイパスできるため、ホストされているサーバーで直接実行すると危険になることがあります。アプレットは、ホストされているサーバーでDoS 攻撃を試みることもありますが、通常、Web サイトを管理する人がアプレットも管理するため、これは不合理です。コミュニティは、ソース コードのレビューや専用ドメインでのアプレットの実行によってこの問題を解決できます。

署名のないアプレットは、元のサーバーでホストされているマルウェアをダウンロードすることもできます。ただし、そのようなファイルは一時フォルダーに保存することしかできず (一時データであるため)、実行して攻撃を完了する手段はありません。この方法で Phoenix および Siberia エクスプロイトを拡散するためにアプレットを使用する試みがありましたが^{[引用が必要]}、これらのエクスプロイトは内部的に Java を使用しておらず、他のいくつかの方法でも配布されていました。

署名付きアプレット^[32]には、ブラウザがリモートで実行されている独立した認証局サーバを通じて検証する必要がある署名が含まれています。この署名の生成には、特殊なツールと認証局サーバの保守担当者とのやり取りが必要です。署名が検証され、現在のマシンのユーザーも承認すると、署名付きアプレットはより多くの権限を取得でき、通常のスタンドアロン プログラムと同等になります。その理由は、アプレットの作成者が判明し、故意による損害の責任を負わされるようになるためです。^{[あいまい]}このアプローチにより、クライアント側スクリプトでは不可能な多くのタスクにアプレットを使用できます。ただし、このアプローチでは、誰を信頼するかを決定するという、ユーザーの責任がさらに必要になります。関連する懸念事項としては、認証局サーバが応答しないこと、証明書を発行するときに署名者の ID を誤って評価すること、既知のアプレット発行者が依然としてユーザーが承認しない操作を行っていることなどがあります。したがって、Java 1.1 から登場した署名付きアプレットには、実際にはセキュリティ上の懸念事項が多くある可能性があります。

自己署名アプレットは開発者自身が署名したアプレットであり、セキュリティ上のリスクをもたらす可能性があります。Java プラグインは、自己署名アプレットの認証を要求する際に警告を表示します。これは、アプレットの機能と安全性は開発者自身によってのみ保証されており、独立して確認されていないためです。このような自己署名証明書は通常、リリース前の開発中にのみ使用され、第三者によるセキュリティの確認は重要ではありませんが、ほとんどのアプレット開発者は、ユーザーがアプレットの安全性を信頼できるようにするために第三者による署名を求めます。

Javaのセキュリティ問題は、クライアント側スクリプトプラットフォームの同様の問題と根本的に異なるものではありません^{[33] [引用が必要]}。特に、署名されたアプレットに関連するすべての問題は、Microsoft ActiveXコンポーネントにも当てはまります。

2014 年現在、自己署名アプレットと署名なしアプレットは、一般に利用可能な Java プラグインまたは Java Web Start では受け入れられなくなりました。そのため、Java アプレットを展開したい開発者は、商用ソースから信頼できる証明書を取得する以外に選択肢はありません。

アプレットで可能な範囲のすべてまたはそれ以上を満たす代替技術が存在します（たとえば、WebAssembly ^[34]やJavaScript）。JavaScriptは、同じページ内でアプレットと共存し、アプレットの起動を支援し（たとえば、別のフレームで、またはプラットフォームの回避策を提供）、後でアプレットコードから呼び出すことができます。JavaScriptの機能とパフォーマンスが向上するにつれて、アプレットのサポートと使用は減少し、最終的には削除されました。

• アクティブX
• Curl (プログラミング言語)
• ジャカルタサーブレット
• Javaウェブスタート
• ジャバFX
• リッチウェブアプリケーション
• ウェブGL

ウィキメディア・コモンズには、Java アプレットに関連するメディアがあります。

• Sun Microsystems の Java 仮想マシンの最新バージョン (ほとんどの Web ブラウザで Java アプレットを実行するためのブラウザ プラグインが含まれています)。
• Oracle からのアプレットの作成に関する情報
• Sun Microsystems のデモ アプレット ( JDK 1.4 – ソース コードを含む)