Java 8はいつまで使えるか ライセンス体系変更でJava業務アプリ、この先どうする?
Java 8アプリの無償サポート終了が目前に迫る。有償に移行するか、OSSに切り替えるか、はたまた他の選択肢を検討するか……。ユーザー企業が選ぶべきは?選定指針を紹介。
通信や金融、公共機関などさまざまな業界の業務アプリケーションで採用されているJava。大規模アプリケーション開発に適したアプリケーション開発言語として広く使われてきたが、近年、開発体制やライセンス体系の変更、サポートライフサイクルの変更などが続いている。本稿では近年の状況と、対策の選択肢やコスト負担のトレードオフの見方を整理する。
Javaの現状を整理する
Javaは、通信や金融、公共機関などさまざまな業界の業務アプリケーションで採用されてきたアプリケーションプラットフォームだ(図1)。大規模アプリケーション開発に適した環境として広く使われてきたが、近年、開発体制やライセンス体系の変更、サポートライフサイクルの変更などが続き、混乱が生じている。企業の重要情報を支える場面で多く使われていることもあり、今後の動向は多くの企業が注目している。
2017年9月、米国のITソリューションベンダーOracleは「Java 9」をリリースした。この時リリースサイクルの変更とサポートポリシーの変更も同時に発表している。具体的には6カ月ごとのリリースサイクルを採用することを宣言している。予告通り、2018年3月にはJava 10がリリースされ、本稿が公開されるころにはJava 11もリリースされているはずだ。
現在、国内でもシェアが多いと思われる「Java 8」は2019年1月で無償サポートが終了する(ただし、個人や公共機関などの非営利、非商用向けは、2020年末までサポート)。Java 11以降のOracle Javaは有償サポートのみになるため、無償でOracle Javaの機能を使ってきたアプリケーションについて「ベンダー都合」をどこまで許容するかは判断が難しいポイントになる。
これは「むちゃぶり」かも? 8割超のJava利用企業が問題の渦中に
下図は、2018年3月にJakarta EEプロジェクトのコミュニティーメンバー1805人に対して行ったアンケート調査の結果だ。Java 9や10がリリースされているにもかかわらず、回答者の約87%はいまだにJava 8を利用していることが明らかになっている。
図3 「WHICH PROGRAMMING LANGUAGES DO YOU USE AT WORK? SELECT ALL THAT APPLY」 Java is consistently either first or second in every reputable programming language ranking on an annual basis. Naturally the participants in this survey had a heavy Java orientation(the survey sought the community’s feedback specifically). It is noteworthy that we are in a truly polyglot world-most enterprises today have developers working in multiple languages. But Java is still the dominant language in back-end enterprise systems.
先に図1で示したように、リリースサイクルおよびサポート期間変更の影響から、Java 8を利用する企業にとっては次の移行は非常に判断の難しい問題だ。まず、2019年1月にはJava 9、10ともに無償サポート期間が既に終了しているため、Java 8利用企業の移行先ターゲットはJava 11しかない。Java 11からは無償サポートは廃止されるため、何らかの有償サポート契約を結ぶ必要がある。
加えて長期サポートライセンスであっても3年ごとの更新が必須となるため、従来のように長期間利用する前提で作り込まれた実装については抜本的に見直しを行わなければ、リリースサイクルに間に合わない事態も予測される。
もちろん終了するのは無償サポートであって有償サポートを契約すれば使い続けられるが、規模の大きな業務アプリケーションの場合はかなりの支出になる可能性もある。
特にサーバサイドJavaを前提とした業務アプリケーションは、重要なワークフローを担っているケースも多く、システム移行の技術検証やテストなどのスケジュールを考えると数カ月単位のリリースサイクルに追従する「準備」ができていない企業がほとんどだろう。アジャイル型のアプリケーション開発に対応できる企業はそう多くない。
コラム:知っているようで知らないかもしれないJavaまわりの用語を整理する
Java SE:
Javaのコア部分を担うAPI群を「Java Standard Edition」(Java SE)と呼ぶ。過去には「J2SE」と呼ばれた時期もある。このJava SEについては、今後も継続してOracleがメンテナンスを行う。
Java EE(J2EE)/現Jakarta EE:
「サーブレット」などの、サーバなどで動作するエンタープライズJavaアプリケーションのためのAPI群を「Java Enterprise Edition」(Java EE)と呼ぶ。過去、J2EEと呼ばれた時期もある。Java EEもOracleが開発を主導してきたが、2017年9月からはEclipse Foundationに開発を移管した。その際、名称はJakarta EEに変更している。
OpenJDK:
元来Javaの開発元であったSun Microsystems(当時)がオープンソースソフトウェア化をもくろんで立ち上げたプロジェクト。現在、アップル、SAPなどの企業が参加して開発を継続している。
Javaアプレット:
Java 9のリリース時にサポート終了を予告されていた機能。代替するライブラリへの置き変えが推奨されている。
選択肢は4つ……かと思いきや5つ? 流動的なJava 8アプリの今後
2019年1月以降のJava 8ユーザーの選択肢は複数考えられる。
(1)Oracle Javaの有償サポートを受けてJava 8アプリを延命する
この選択をした場合でも2020年にはJava 8のサポートが切れるためJava 11などへの移行計画は検討する必要がある。
(2)OpenJDKに移行して無償サポートを受ける
OpenJDKに移行し、OpenJDKのリリースサイクルに従ったアップデートサイクルを順守する(6カ月ごとのリリースサイクルに対応する)
(3)Oracle以外のベンダーの有償サポートを受けてJava 8アプリを延命する
具体的には、レッドハット、富士通、日立、IBMなどが独自にサポートを行っている。例えばレッドハットの場合、OpenJDK 8のサポートを2020年10月までとしており、それ以降については、OpenJDK11に移行することを条件に長期サポートを提供すると表明している。また、IBMの場合、IBM JavaのSDKを利用したアプリケーションに限り、少なくとも2025年までは独自の延長サポートを行うと表明している。また、それ以降も各社が独自にJava 11のサポートを行う計画がある。今後もJavaアプリケーションを運用する場合は、周辺業務アプリの改修や刷新計画と合わせて、他の製品やサービスと連携しやすいベンダーが提供する実行環境に移行する計画を立てるのも1つの方策だろう。
(4)Java 11に移行してLTSサポートの契約を締結、過酷な短期リリースサイクルを回避
半年おきのリリースサイクルに追従できない場合はJava 11から提供される長期有償サポート(LTS)を受ける。LTSの場合もサポートサイクルは決して長いわけではなく、3年であることには注意したい。Java 11への移行に際しては、それ以降のバージョンアップ作業を軽量化する方法も検討しておく必要がある。
ここまでは既知の対処方法としてJavaユーザーの間でも議論されてきた方法だが、2018年6月、OracleはJava8ユーザー救済策として、Oracle Java SE Subscriptionを発表した。これにより、Oracle自身による低価格でのサポ−トを受ける選択肢も検討できるようになった。このため、新たに選択肢(5)を検討することもできる。
(5)Oracle Java SE Subscriptionを契約してJava 8のサポートを継続する
Oracle Java SE Subscriptionは2025年までサポートを継続するとしており、低価格で利用できる点が特徴だ。
日本オラクルの公式FAQによれば、プロセッサライセンスの場合は「サーバまたはクラウド・デプロイメントでの利用に対して月々3000円以下」(2018年8月3日現在)としている(デスクトップライセンスもあるがここでは割愛する)。
対応が間に合わず、かつサポートなしでの利用が許されない場合、状況によっては高額なサポート費用負担が発生する可能性がある。少なくともサーバサイドで動作させるJavaでセキュリティ面での問題をクリアしたい場合には、緊急でサブスクリプションライセンスの予算を見積もっておく方法も考えられる。
アプリケーションの根本的な変更は是か非か
ここまで見てきたように、Javaアプリケーションの今後はまだまだ混乱が多く、状況は流動的だといえる。ベンダーの都合でやや騒動になってしまった点は利用者にとって不幸なことに間違いない。だが、開発の主軸がコミュニティーベースになったこと、参加ベンダー各社がエンタープライズJavaの企業資産を保護するために多様な提案を用意し始めている点は、利用者にとって選択肢が増えることにつながるため、総じてプラスといえる状況だろう。レガシーマイグレーションをキーワードに、Java実行環境の乗り換えを起点としたクラウドと親和性の高いマイクロサービス型のアーキテクチャへの変換シナリオを提案するベンダーも多い。クラウドの利用や機能単位での開発や継続的インテグレーションなどにも取り組みやすくなり、将来的な開発工数や運用費用削減も期待できるだろう。
今後のJavaアプリ運用上のコスト算出の際は、こうした周辺環境の発展性や運用の現代化による効果も見込んだ評価を行うと発展的な提案に導きやすくなるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- SAP ERPの「2025年問題」とは? 概要と対策
人手不足が本格化するといわれる2025年。この年、企業の基幹業務を支えてきた古い「SAP ERP」の保守サポートが終了する可能性がある。導入プロジェクトをけん引してきた人材が不在になる前に検討しておくポイントは? - この数年で大転換を迫られる企業IT、時系列で分かる「何をいつまでにどうすればよいか」
Windows Server 2008のサポート終了への対応に注目が集まるが、問題はそれだけではない。これから2025年までの数年は企業情報システムの大転換期になる。いつ何がどうなるかを整理した。