1. はじめに
前回の記事を書いた際、Oracle JDKが有償化されたことに関して色々と意見を目にしました。Java界隈は激震に揺れているとか、もう無料で使い続けることはできないとか、OracleがJavaを握っていること自体がリスクであるとか、そんな中で「良い感じ」などと何を呑気なことを言っているのか、etc...
私自身Javaに関して純粋なプログラミング知識以外の部分は詳しくないため、あまり触れないでおこうかなと思いました。しかし「良い感じ」などと書いた手前、それなりに考えておいた方が良いかなと思い、ちょいちょい調べて本記事を書くことにしました（間違っている部分はご指摘頂けると助かります）。
では何を題材にするかですが、Oracle JDK有償化に対する批判や、Java界隈の動向への意見の中で、少し方向性が違うものが多いんじゃないかという印象を受けました。少なくとも、言語仕様とOracle JDKの有償化はある程度切り離して考えることができるかと思います。このあたりを混同しないために、一旦現状を整理した上で今後の動向について述べて行きたいと思います。
2. 現状の「Java」を再確認
Javaは誰のもの？
とりあえず強調したいのが JavaはOracleのものではなく、コミュニティのものとされていることです。
少し前になりますがOracleのWebサイトにそれを主張する記事があり、今後も変わらないであろうと考えています（理由は以降の説明に含まれています）。
「Javaはオラクルのもの？」、「いいえ、これからもJavaコミュニティのものです！」
Javaの仕様はコミュニティが決定する
Javaの仕様は、Oracleが決定するのではなく、JCP（Java Community Process）が決定します。「JCP」とは、についてはIT用語辞典からそのまま引用させて頂きます。
JCPとは、Java関連技術の開発や仕様の標準化プロセスを公開している国際的機関の名称である。Sun Microsystems社によって1998年に設立された。
JCPは企業や個人の会員から成り立っている。個々の会員には公開前のJava関連技術を評価して仕様の改訂などを要求する権利が与えられている。対象となる技術は、言語仕様やプラットフォーム、アプリケーションプログラミングインタフェースなどとなっている。
JCPの会員は個々にライセンスを持ち、Javaにおける互換性が保証されている限りにおいてTCK（Technology Compatibility Kit）に基づいた独立仕様を実装することができる。一般の企業会員は有料で会員となることができるが、個人や教育団体、非営利組織などは、JSRのTCKに無料でアクセスすることができる。
JCPは、OracleがSunを買収したときに存在が危ぶまれたらしいですが、それは杞憂に終わっています。また今後も続いていくものと思っています。
Java仕様の最終的な決定は、投票権を持つJCPメンバーによる投票によって行われますが、これに対してOracleは特別な投票権をもっているわけではありません(確か)。
なお、JCPについてより詳しい情報は以下を参考にしてください。
JCPとOracleの関係
既に挙げたOracleのWebサイトに次のような説明があります。
それでは、Javaに対するオラクルの立場とは、どのようなものなのでしょうか？ オラクルは、JCPのPMO（Program Management Office）であり、いわばJavaとJCPの管理人的な存在です。例えば、JCPで何かを決める際には、だれかがそのプロセスをモデレートしなけれ ば、プロセスがスムーズに進みません。オラクルはJavaの管理人として、そうしたプロセスが円滑に進むようお手伝いしているのです。
個人的な考えですが、Oracleが現在の立場をひっくり返してJava仕様決定権の全てを独占する可能性はさすがに無いと考えています。コミュニティの力もあってここまで発展したものを独占してしまえば、企業としてもJavaとしても大幅なイメージダウンは免れないでしょう。
「Java製品」とは
TCK（Technology Compatiblility Kit/技術互換キット）によって合格判定を得た製品が「Java」製品として認定されます。昨今話題のOracle JDKも「Java製品」の一つであり、またそのうちの一つに過ぎません。TCKに合格した「Java製品」であれば、どのディストリビューションを使っても表面的には同じ挙動をするはずです。
そのため、今後Oracle JDKから別のものを使うようにしたとしても、製品の独自機能を使わなければ、プログラミングを行う上でどのディストリビューションを使うかは基本的に気にしなくて良いでしょう。
OpenJDKとOracle
OpenJDKはSunの時代から様々な変遷を経て生まれたオープンソースプロダクトで、現在世の中に出回っているJava製品は、多かれ少なかれOpenJDKが元になっているようです。OracleはOpenJDK開発に対して多大な貢献をしており、今後も継続していくことを明言しています。
参考：JDK、Oracle JDK、OpenJDK、Java SEってなに？
参考：【Oracle Code One 2018】堅実な一歩がJavaの進化を促進する
リリースモデルの刷新
リリース間隔が長く、言語そのものの進歩が遅いという批判に対して、Java9以降のリリースモデルが見直され、半年に一度メジャーバージョンアップが行われるようになりました。
ただし、リリースサイクルが早まったことが主な変更点であり、仕様変更・追加が劇的に増えたわけではなさそうです。そのため、後方互換性が著しく低下する懸念は今のところ気にしなくて良いのではと考えています。実際、話を聞いているとJava9以降のアップデートはほとんど問題なく行えているようです（Java9の問題については後で説明します）。
参考：Java 9のその先へ～JavaOne Conference 2017レポート
参考：新しいリリースモデルを採用した今後のJava、入手方法やサポート期間はこう変わる
Oracleの貢献
好き嫌いの感情はともかく、Sunの意思を引き継いだコミュニティ発展、バイナリ含むJava製品の長期間に渡る無償提供、OpenJDKの開発など、OracleがJavaに対して多大な貢献を行ってきた、というのは疑いようのない事実ではないでしょうか。そのため、Oracle JDK有償化だけ取り上げてOracleを非難するのはちょっと違うかなと思います。
また、有償化により得た資金がGraalVMなど面白い試みに投資されることを考えれば、一般の開発者としてもデメリットばかりな話でもないかと思います。
ただし、OracleはOpenJDKに対するLTS（Long-term Support）については明言を避けてきており、少なくともJava11に関してはなんだかんだで実現しない模様です。もし、早期にLTSが保証されていれば、そもそもあまり騒動にならなかった気がしていますが、このあたりが難しいところです。これに関しては後で考察します。
3. Oracle JDK有償化の意図とは
※以下の内容は完全に個人的な見解です。見当違いな考えである可能性を考慮してお読みください。
OpenJDKのサポートを明言しつつもLTSは避けているところが読みにくいところですが、自分なりに考察してみます。
有償Oracle JDKのターゲットは誰？
世の中には、無償のオープンソース製品よりも有償で有名企業がサポートする製品を好む人が確実に存在します。Oracleは、自社ブランドおよびOracle JDKの実績を名目に、これらの人、企業に対して有償に切り替えようしているのではないか、と考えています。
OpenJDKへのサポートについて
Oracle JDKは有償化するものの、大勢のJavaユーザ、およびそれが支えるオープンなコミュニティは残しておく必要があるため、OpenJDKへのサポートを止めるべきではないと考えている模様です。
しかし、OpenJDKに対するLTSを明言してしまうと、今度はOrcleJDKとの差別化が図れず埋没してしまう恐れがあるため避けているのだと考察しています。このあたりが匙加減の難しいところで、混乱を招いている原因かと思います。
第三者によるOpenJDKのLTSサポートへの期待
実はこの記事を書いている最中にかなり衝撃的なニュースが飛び込んできました。
【速報】マルチプラットフォームで利用可能なOpenJDKのAmazon Correttoが発表されました！
しかし、Oracleはこのような流れを待っていたような気がします。上で説明したOracleのターゲット層と被らず、Oracle JDKとそれ以外でパイの奪い合いには発展しないと張っているのでは、と考えています。
また、これによりJavaのユーザ離れを引き止め、ひいてはコミュニティの維持に繋がることが期待できます。さらにOpenJDKに対するOracle以外のサポータが増えれば、Oracleにとってはデメリットが少なく良い流れかと思います。
4. 今後の動向の注視ポイント
Javaが分裂する可能性は低い
ここまで大きく発展したJavaコミュニティの分裂はデメリットが大きすぎるため、さすがに避ける方向で動くと思われます。よって、例えばJavaそのものがforkして別プロジェクトが生まれユーザを奪い合う、なんてことにならないと思っています（そもそも実現性がない？）。
OpenJDKとOracle JDKのパワーバランス
OracleのOpenJDKへの貢献活動がどれほど継続されるか、OpenJDKがOracle JDKのシェアを奪うのかどうか、この辺のバランスでしょうか。
個人的には上で説明したとおり、OpenJDKが有償Oracle JDKのシェアを奪うことには繋がらないと予想していますが、この予想が外れた場合Oracleがどう動くか気になるところではあります。
どのディストリビューションを使うか
無償でJavaを商用利用し続ける場合、どのディストリビューションを使うかに、ついてです。今のところAmazon Correttoが最有力な気がしますが、状況が落ち着くまで（あるいはそもそも落ち着くのかどうか）当面注視する必要があるかと思います。
5. 実際の現場が今後取り組むべきこと
これまで述べてきたことを踏まえた上で、Javaユーザが今後取り組むべきことについて、少し考えを述べておきます。
Java9の壁を乗り越える
基本的にメジャーなバージョンアップであっても高い後方互換性を持つJavaですが、Java8からJava9以降へのバージョンアップだけは注意する必要があります。モジュールシステムの導入により、表面的にはあまり変わらないように見えて、内部的にドラスティックな変更が入っています。コンパイルが通ったとしても、そもそもアプリが起動しないとか、動作中に動かなくなるといった可能性が結構あります。
そのため、Java9の壁の乗り越えは早めにやっておいた方が良いでしょう（今更な感じですが）。
参考：Java 9のその先へ～JavaOne Conference 2017レポート
テスト自動化の仕組みを導入する
OpenJDKに対するLTSが立ち行かなくなり、頻繁にアップデートを行う必要が出てきたときのためにも、テスト自動化の仕組みは取り入れるべきかと思います。またLTS中であっても、重大なセキュリティ脆弱性が見つかればバージョンアップ作業は発生するため、どの道、導入しておくべきかと思います。
前回の記事の記事でも触れましたが、テストフレームワークが充実しているものもあり、うまく使えればバージョンアップ作業コストを抑えることができます。
6. おわりに
最後に気になるところを少し。
Java以外のバージョンアップ作業はどうなっている？
前回の記事を書いた際、Javaに対するバージョンアップ作業へのコストを懸念する意見がいくつか見受けられましたが、当然ながらバージョンに関する問題は他の言語でも存在するかと思います。
Java自体は後方互換性が高く、コンパイル言語であることもあって、バージョンアップ作業はかなり容易な部類に入ると思っています。言語によってはマイナーバージョンアップであっても互換性が保たれないものもあるかと思いますが、そのあたりどう対応しているのでしょうか。
また、バージョンアップ作業コストへの懸念によりJavaから他の言語、フレームワークに切り替えたというケースについては、その言語、フレームワークを選定する際、セキュリティ面、バージョンアップ作業容易性、テストフレームワークの充実度なども考慮に入っているのか、とても気になるところではあります。
現状をどの程度知っている？
この記事で触れたJavaの現状を把握した上での批判およびJava離れであれば、正直何も言うことはありません。
もし初めて知った内容が多いのであれば、これを機に、Javaについて色々と調べたり考え直してみてはいかがでしょうか。
この記事での見解が的外れであったとしても、現状を再認識して今後の動向を考察するきっかけになれば幸いです。
以上、最後までお付き合い頂きありがとうございました。