原文はこちら。
The original article was written by Phil Race (Consulting Member of Technical Staff, Oracle).
https://inside.java/2025/12/03/applet-removal/
JDK 26（2026年3月リリース予定）より、java.appletパッケージ全体が削除されます。（ベンダーにより異なりますが、LTSリリースである）JDK 25が、java.applet APIを含む最後のJava SEバージョンになります。これはJEP 504: Remove the Applet APIに基づき実施されたもので、削除の背景とタイミングについては説明が必要と考えられます。
JEP 504: Remove the Applet API
https://openjdk.org/jeps/504
A Bit of Background About Applets
java.applet.Appletクラスは、1996年にJDK 1.0と共に提供された当初から、Javaプラットフォームの基盤となるクラスでした。当時、Javaの主な用途はappletを中心に展開しており、これらは共有仮想マシン上で動作する小さなプログラムで、当時のブラウザ（主にNetscape NavigatorおよびJavaブラウザプラグイン経由のInternet Explorer）に組み込まれることが一般的でした。Appletにより初期のHTMLでは実現不可能な機能レベルが追加されました。
これらの小さなappletのライフサイクルは、java.applet.Applet APIが規定していました。Java appletはHTMLと同様にWebサーバーからダウンロードされ、<APPLET>タグがサポートされている場合にappletが実行されました。これは、ローカルにインストールされたJavaプラグインがプラットフォーム非依存のバイトコードをシステムに橋渡しするためでした。
appletは、ビジネスアプリケーション、ゲーム、その他の消費者向けアプリケーションにおいて、web上のユーザー体験を向上させるために使用されました。Java Security Managerはこれらのappletをサンドボックス化し、ダウンロードした信頼できないコードがユーザーの許可なしにローカルシステム上の何かにアクセスしたり、元のホストへの接続を除いてネットワーク接続を行ったりできないことをエンドユーザーに保証しました。また、印刷を行うにはエンドユーザーに直接許可を求める必要がありました。これらは当時、画期的な技術でした。
The World Is Now Different
デプロイメントモデルが変化し、ブラウザがプラグインモデルのサポートを終了したため、現代のwebブラウザではappletの実行は不可能になりました。ただし、webブラウザやダウンロードされた信頼できないコードのシナリオ以外では、java.applet APIパッケージがエンドユーザーアプリケーションに役に立つケースは稀であり、そのため長らくjava.desktopモジュールの中でほとんど役目を果たさない部分でした。
スタンドアロンのJDKは、APIを提供していたにもかかわらず、それ自体でappetを実行する手段を一切提供したことはありませんでした。OpenJDKプロジェクトの一部ではなかったJavaプラグインや、開発者テスト用のバンドルツールのappletviewer、開発者専用ツールであるJDK回帰テストフレームワークのjtregなどが実装を提供していました。決定的な要因は、JDK 24でJava Security Managerが恒久的に無効化されたことで、信頼できないコードを実行するためのサンドボックス環境が不可能となったことです。
JEP 486: Permanently Disable the Security Manager
https://openjdk.org/jeps/486
そうして、最新のtip JDKからapplet APIを削除する時期が到来しました。長年にわたるappletの歴史と多様な利用状況を考慮し、この削除は数多くの警告、準備、検討を経て実施されました。
JEP 14: The Tip & Tail Model of Library Development
https://openjdk.org/jeps/14
java.appletの削除に向けた準備作業は2016年から継続する10年にわたるプロジェクトです。まずJDK 9において非推奨 (deprecated) になり、続いて2021年のJDK 17では削除に向けた非推奨化 (deprecated for removal) が行われました。また、バンドルされていたappletviewerツールはJDK 9で非推奨化され、2018年のJDK 11で削除されました。数千に及ぶJDKのjtregベースの機能テストを更新し、applet APIに依存しないようにする作業や、appletに言及している仕様の微調整などに多大な労力が費やされました。
JEP 289: Deprecate the Applet API
https://openjdk.org/jeps/289
JEP 398: Deprecate the Applet API for Removal
https://openjdk.org/jeps/398
[JDK-8074165] AppletViewer is deprecated
https://www.oracle.com/java/technologies/javase/9-all-relnotes.html#JDK-8074165
[JDK-8200146] Remove the appletviewer launcher
https://bugs.openjdk.org/browse/JDK-8200146
このように、削除に至るまでに10年を要したのです。どうか「ちょっと他のところを見ていたら、どういうわけかこれらのメモを全て見逃してしまった」などと言わないでください。
So What Now?
JDK 8アップデートでは、ますます稀になるレガシーブラウザ環境向けのappletのサポートを継続するとともに、Java Web Start (JNLP) 対応のappletもサポートしております。
開発者の皆様には、エンドユーザーへの Java アプリケーションの配布には jpackage のご利用をお勧めいたします。この JDK 提供ツールはネイティブプラットフォームのインストーラを生成するため、Java プログラムは他のアプリケーションと同様にシステムにインストールします。
スタンドアロンのAWT/Swingアプリケーションでapplet APIを使用しているものはごくわずかであり、移行が可能と考えられます。java.applet.Appletクラスは単にjava.awt.Panelのサブクラスであるため、Applet固有のメソッドを使用していない限り、移行は容易です。デスクトップアプリケーションにおいてこのようなケースは極めて稀であり、一般的にこれらのケースでは有用ではありませんでした。
一部のユーザーからは、appletにApplet APIを使用せず、アプリケーション内で便利な音声再生APIとしてjava.applet.AudioClipを利用していたとの報告がありました。JDK 25では、その代替としてjavax.sound.SoundClipを導入しております。
Applet APIからの移行について追加のサポートが必要な場合は、サポートプロバイダーにお問い合わせください。
JDK内のjava.desktopモジュール（すなわちAWT、Swing、Java 2D）といったその他の部分は、機能面での影響はなく、引き続きサポートおよび強化が行われます。
Logico Inside 