Javaのアップデートしてますか？
Javaは、1995年にUNIXベンダーとして有名でだったサン・マイクロシステムズによって公開されました。マルチプラットフォームをコンセプトとしたプログラム言語として、発表当時は世界に大きなインパクトを与えました。
それから数十年、機能追加が繰り返し行われ、2021年1月時点での最新バージョンは「Java 15」となり、今での日々アップデートが行われ、当時に比べると非常に多くの機能が加えられ、さらに使いやすく改良されています。
しかし、Javaは時々ニュースになるほど、深刻な脆弱性（セキュリティホール）が見つかることがあります。
例えば、Javaのセキュリティーアップデートであるjava 8 update 131では、実に299件のセキュリティ問題が修正され、その中には、共通脆弱性評価システム（CVSS）のベーススコアで危険度が最大値の10.0とされた深刻な脆弱性も存在しました。
脆弱性を悪用されると、リモートからの攻撃によって Java が不正終了したり、任意のコードが実行され重要な顧客情報などが盗まれる恐れがあり、速やかに脆弱性（セキュリティホール）が修正されたパッチを適用する必要があります。
基本的には、深刻な脆弱性（セキュリティホール）が見つかると、速やかに修正が行われ、前述のjava 8 update 131のような形でセキュリティパッチが配信されます。
しかし、Javaを自動更新するように設定していないと、セキュリティパッチが自動で適用されず、脆弱性（セキュリティホール）を抱えたまま運用することとなり非常に危険です。
サポートが切れたJavaを使い続けると…
Javaの各バージョンにはサポート期限が定められており、サポートが切れたJavaのバージョンには、その後に深刻な不具合や脆弱性が見つかった場合でも、セキュリティパッチは基本的に公開されません。
サポートが切れたバージョンのJavaを使い続けると、脆弱性（セキュリティホール）を攻撃され重要なデータが盗まれるなど、非常に危険な状態でシステムを運用することになります。
昨今の社会事情からひとたび情報流出が発生すると、企業イメージに深刻なダメージを受け、顧客企業などとの今後の取引に影響を及ぼすばかりか、最悪の場合は訴訟に発展するケースもあります。
外部からのアクセスがなく、社内のネットワーク内からしかアクセスされないシステムであれば、コスト面などを考えて、サポートが切れたバージョンを使い続けるという判断もあるかもしれませんが、サポートが切れたバージョンは、不具合も修正されることもないので、基本的には新しいバージョンに更新することをお勧めします。
外部からアクセスがあるようなシステムでは、当然サポートが付いたバージョンを使うようにしましょう。
以下の表は、2021年1月時点のJavaのサポート状況です。
| バージョン | 公開 | Premier Support | Extended Support |
|---|---|---|---|
| 7 | 2011年7月 | 2019年7月 | 2022年7月 |
| 8 | 2014年3月 | 2022年3月 | 2030年12月 |
| 9（非LTS） | 2017年9月 | 2018年3月 | なし |
| 10（非LTS） | 2018年3月 | 2018年9月 | なし |
| 11（LTS） | 2018年9月 | 2023年9月 | 2026年9月 |
| 12（非LTS） | 2019年3月 | 2019年9月 | なし |
| 13（非LTS） | 2019年9月 | 2020年3月 | なし |
| 14（非LTS） | 2020年3月 | 2020年9月 | なし |
| 15（非LTS） | 2020年9月 | 2021年3月 | なし |
Java6以前のバージョンは表に載せていませんが、すでにサポートが切れています。
Java 7についてもサポート期限が迫ってきており、そろそろ移行を検討する時期に入ってきました。
Java9からはバージョンアップは半年ごとになり、およそ３年おきにJava11のようなLTS版（長期サポート）のJavaがリリースされるようなサイクルに変更されました。（次のLTS版はJava17となる予定）
非LTS版のJavaは、次のバージョンがリリースされるタイミングでサポートが切れるように設定されおり、そのためJava 14はサポートが切れているが、それより前にリリースされたLTS版のJava11のサポートはまだ当分続くような状態になります。
意外と簡単？Javaのバージョンアップ
サポートが切れたJavaを使い続けるのは危険であることは分かりました。
Javaバージョンアップは、ただ新しいバージョンのJavaをインストールするだけでなく、古いバージョンを使ったJavaアプリケーションのマイグレーションが必要になります。
マイグレーションは具体的に、廃止になったAPIを代わりとなる新しいAPIに書き換えたり、同じAPIでも動作に非互換がある箇所の修正を行います。
また、プログラムの修正が完了したら、システムの全体的な動作を確認したり、旧バージョンと新バージョンで比較確認を行い、問題を抽出し修正を行います。
上の内容を見ると、とても大変な作業でコストもかかりそうですが、実際はそうでないこともあります。
下位互換により実際の修正は少ない
Javaは、基本的に下位互換性があるように設計されています。
そのため、例えば Java 6から Java 7や8へアップデートする程度の少ないバージョンアップであれば、ほとんどソースコードを修正することなくマイグレーションできます。（もちろん新旧比較などのテストは必要です）
各バージョンの互換性
最後に、Javaの各バージョンの互換性について紹介します。
【Java8の互換性 (7からの変更点) 】
Java 8は、Java 7の強い互換性があり、ほぼすべての既存プログラムが変更を加えずにJava 8で動作します。
ごく一部のコードは、変更が生じる可能性があるとOracle社は公表していますが、ほとんどのケースで変更は必要はないでしょう。
【Java9の互換性 (8からの変更点) 】
Java 9ではJava EEに由来する次のモジュールが非推奨になりました。（後のJava11で削除）
- java.activation
- java.corba
- java.transaction
- java.xml.bind
- java.xml.ws
- java.xml.ws.annotation
また、Java 9で追加されたモジュール機能により、sun.securityなどのJDK内部クラスが、アプリケーションから参照できなくなりました。もしsun.securityなどを参照しているコードが存在した場合、コンパイルエラーとなります。
さらに、java.awt.peerおよびjava.awt.dnd.peerパッケージはJava 9以降で削除されたため、コンパイルエラーとなります。
【Java11の互換性 (9からの変更点) 】
Java 11では、Java 9で非推奨となったJava EEに由来するモジュールが削除されしました。
また、標準からJAX-WSが削除され、続けて使用する場合はjaxws-api及びjavax.jws-apiを依存菅家のライブラリに追加する必要があります。
この記事では、Javaの各バージョンにおける大きな変更点のみ記載しましたが、細かいところでは様々な変更が行われています。
詳しくは、Oracle社公式の移行ガイドなどを参照してマイグレーションを行うようにしましょう。
少ないバージョンアップであればよいですが、Java 1.4 からJava 11など、一気にバージョンを上げるとなると、多くのソースコード修正が発生しテストの工数も膨れ上がります。
このように、コストを気にしてバージョンを延期してしまうと、そのツケを未来に払うことになり、その時の状況次第では膨大なコストに対する予算がつかず、システムが更新できず最悪の場合はシステムが動作しなくなる恐れがあります。
サポートが切れるタイミングで適度にバージョンを上げることも重要です。