TL;DR
- 削除機能はクライアント寄りが多い
- 多くの削除機能に代替策が存在する
- Security Managerに直接の代替策は存在しないため、クライアント実装は注意が必要
はじめに
Javaはエンタープライズ向けの言語であることを意識して、後方互換性が重視されています。そのため、過去に作成したコードがそのまま最新のJDKでもほぼ動作します。
ただ後方互換は完全に保証されたものではありません。時代の流れで役目を終えた機能や、Java本体とは別に管理すべきと判断されたコンポーネントは、まず非推奨（deprecated）とされ、その後削除（removed）されてきました。
この記事では、現在も多く利用されておりモダナイズの必要性があるJDK8から最新のJDK25のあいだで削除された機能を確認していきます。
すべての削除機能を網羅した記事ではありません
GCアルゴリズムの変更など性能チューニングに関わる話は対象外とし、アプリケーションとしての機能が提供できなくなるためアプリの仕様変更が必要になるトピックのうち大きいものを対象にしています。
同じ期間に行われた変更として「JavaEE→JakartaEEのパッケージ名変更」が大きなトピックとして存在しますが、この記事ではJDKにフォーカスしているため対象外としています。
削除された機能たち
CORBAとJAX-WS （Deprecated: 9 Removed: 11）
自アプリケーションから他機能を呼び出すための規格として利用されてきたCORBAやJAX-WS（SOAP通信で使用）などが削除されました。
CORBAはアプリ連携のI/Fとして活用されてきましたが、旧式ということで削除対象になっています。JAX-WSやトランザクション系のAPIはJavaEE/JakartaEEでの管理が望ましいということで削除されており、現在はJakartaEEの1機能として提供されています。
参考までに、アプリ連携方式のひとつであるRMIはまだ提供されています。
ただ、機能の一部である「RMIによる相手先モジュールの自動起動（RMI Activation）」はJEP407で削除されています。こちらはゼロスケール発想のご先祖様みたいな機能ですので、今はREST＋ゼロスケール実装でカバーできるでしょう。
アプリケーション側の対応方向性
- 代替モジュールへの移行: CORBAであればEclipse ORB、JAX-WSはJakartaEEの利用が考えられます
- 他連携方式への移行: CORBAであればgRPC、SOAP(JAX-WS)であればRESTへの移行が考えられます、ただし接続先との協調が必要です
参考記事
Nashorn JavaScriptエンジン（Deprecated: 11 Removed: 15）
最近はあまり注目されませんが、Javaアプリケーション内でJavaScriptを処理する機能があります。歴史を遡るとJDK6の頃にJavaの適用範囲を拡張させるために導入されたようです。
実際の利用シーンとしては、リコンパイルせずにスクリプトファイルを置き換えることで細かい制御を管理・変更するというユースケースが思い浮かびます。
実行エンジンとしてRhinoと呼ばれた初期バージョンから始まりNashornという高効率のエンジンに置換されました。ただJavaScript規格の進化が早く、JDKの機能として継続提供することが困難という理由でエンジンの搭載が廃止されています。
アプリケーション側の対応方向性
ここで削除されたのは実行エンジンのみで、スクリプトを呼び出すためのI/Fは残されています。ですので、実行エンジンを外部から追加する対策が考えられます。
GraalJSはNashornからのマイグレーションガイドも存在することから、移行先の有力候補になるでしょう。
参考記事
Applet（Deprecated: 9/17 Removed: 26）
インターネットが商用で普及しはじめる前、エンドユーザーが使うアプリケーションはモバイルアプリのようにローカルインストールする形が一般的でした。
ただ企業内運用ではインストール・更新の運用が煩雑でした。そこで「ブラウザは最新のリソースを閲覧できる」という特徴を生かして「HTML内に画像のようにアプリを埋め込んでしまおう」という発想で実現したのがアプレットというアプリケーションコンポーネントです。
ブラウザの表現力が向上してアプレットで実装する必要性が薄れてきたこともあり、JDK9の時点で非推奨化、17で削除予告、24でのSecurity Managerの廃止に合わせて完全削除という経過をたどりました。
アプリケーション側の対応方向性
次のようなパターンが考えられます。
- モダンなフロントエンド技術への移行: 長期でアプリを活用する場合の第一選択
- スタンドアロンアプリケーションへの移行: 元のコードを再利用したい場合は、Appletとしてラップしないスタンドアロンアプリケーションへ移行することが考えられますが、配布運用や実行環境のセキュリティ設計などを検討する必要があります
- ソリューションによる解決: 機能の存続を優先させる場合、ブラウザにJVMを埋め込むcheerpjというソリューションもあるようです
参考記事
Security Manager（Deprecated: 17 Removed: 24）
Java 1.0から存在する、歴史の長いセキュリティ機構です。
モバイルアプリでは、カメラや位置情報、電話といったリソースへのアプリのアクセス要求をユーザーが承認判断しています。Security Managerはこの役割を担っており、リソースアクセス制御をポリシーファイルで細かく制御するという機能です。
クライアントでJavaアプリを実行する際の環境保護に必要でしたが、そのユースケースがなくなりつつあり、サーバーサイドでは元から利用されることはほとんど無かったかと思います。
その利用率の低さと反比例するように保守コストが高かったため、削除の判断が行われました（JEP411、486に目を通すと、削除を渇望するJavaコントリビューターの熱量が感じられます）。
アプリケーション側の対応方向性
該当するアプリケーションはほとんど存在しないと思われますが、Security Managerを使った制御が行われているアプリがあるとしたら、OSやコンテナなど外部のセキュリティ管理機能を使った制御で代替すべきかもです。ここはアプリケーションの事情により様々な選択肢がありそうです。
多くのアプリケーションでは影響ありませんが、ライブラリ内でサンドボックス化のために利用しているケース（例：プラグイン実行基盤など）は注意が必要です。今後はJava言語内の機能に頼るのではなく、OSやコンテナのセキュリティ機能などを駆使した代替策を検討してください。
Java FX（Removed: 11）
Javaは現在サーバーサイドでの利用が主流ですが、フロントエンドの実装にも利用されていました。次のようなライブラリが順に登場しました。
- AWT: OSネイティブUIを活用、OSにより見た目が異なる
- Swing: OSに依存しない統一的なUIを提供する
- JavaFX: SwingよりリッチなUIや開発体験を提供する
JavaFXがもっとも高機能なUIライブラリといえます。
JDK9以降は半年毎のリリースとなり開発のペースが合わないなどの理由により、JDKより分離するという扱いになりました。
現在はOpenJFXというプロジェクト名で存続しています。プロダクト名はJavaFXのままのようです。
参考までに、Swingは今もJDKに含まれています。JMeterなどのプロダクトでは現役で利用されているようです。
アプリケーション側の対応方向性
OpenJFXにそのまま移行する形が第一選択になりますが、環境によってはモダンなフロントエンドへの移行も選択肢としては挙げられるでしょう。
参考記事
開発者のネクストアクション
マイグレーション戦略を考える
マイグレーションを支援するツールが存在しますが、全てツールに依存すると出力内容の理解に時間がかかるかもしれません。今回の記事のように「何が削除されたか」は予め理解しておくと対応が捗るでしょう。
今回は対象にしていませんが、マイグレーションには次のような対処も必要です。
- 外部ライブラリのバージョン整合性確認
- 機能削除以外の大きな変更（JEP 400: UTF-8 by Default はWindows環境では要注意）
- JakartaEEへの移行戦略
IBMが提供するマイグレーション対応製品
IBMではJavaモダナイズを多彩なツールで支援します。ツール利用による効率的なマイグレーションを検討してください。
| 製品 | 機能 | URL |
|---|---|---|
| IBM Transformation Advisor | 移行対象のリソースを分析し、マイグレーションに必要な修正箇所をサジェストします | 製品紹介 |
| IBM Application Modernization Accelerator（AMA） | Transformation Advisorに高度な解析機能と修正支援機能が追加されています |
製品紹介 インストール |
| IBM Bob | AI支援が可能な開発ツールであるBobにJavaモダナイズの機能が付与されています |
体験記 AMAとの併用 |
ITの機能整理を開発ループに取り入れる
今回確認したOpenJDKの更新プロセスからの学びとして「不要機能の削除はアップデートを容易にする」ということが挙げられます。
これは業務アプリケーションも同じことで、習慣的に不要な機能・コードを積極的に廃止することはコードの複雑性を下げ、長期的な保守コストの削減に寄与します。
今後のAIを活用した開発でも「不要機能の削除でコンテキストを小さくすることでAI利用コストを低減しつつ精度を上げる」ことに繋がるのではないでしょうか。
とはいえ現場では「動いているコードに触るな」「利用機会は稀だがゼロではないから削除するな」という保守的な意見も根強くあります。そのような場合には、客観的な利用状況の観測データを提示して議論することが有効です。
IBMが提供する観測に寄与する製品
IBMでは上記ニーズに応える多様な観測系のツールを提供しています。
| 製品 | 機能 | URL |
|---|---|---|
| IBM Turbonomic | 利用率の低いITリソースを可視化することで、削除の根拠を数値で示せます | 製品紹介 |
| IBM Process Mining | 利用率の低いビジネスプロセスを特定することができます | 製品紹介 |
おわりに
JDKの更新はユーザーにとって大きなイベントで、影響が未知数であると更新の判断は鈍くなります。ただ今回改めJavaて整理してみると大きな影響がないパターンに該当しているかもしれません。
現実的にはテスト工数などは確保する必要があるものの、
- 影響する範囲の大枠を理解する
- ツール利用で実際の移行は自動化できる部分が大きい
という2点を念頭に置くことで、合理的な意思決定が行いやすくなるのではないでしょうか。
またJDK開発の運用に学び、不要な機能を適切に削減してスリムにすることが長期目線で運用コストの削減につながる可能性も探ることができると考えます。
適切なガバナンスを通じて、より価値の高いシステムを提供していきましょう。