本記事はOracle Code Oneレポートの第2回ですが、単体で読める構成にしています。なお、初日のJavaキーノートの詳報をお伝えした第1回のレポートはこちらから参照ください。
JavaOne から Oracle Code Oneに改称した理由と、そのキーノートに込めた意図
――1996年から続く歴史あるカンファレンスである「JavaOne」ですが、今回、その名称が「Oracle Code One」に変わりました。今このタイミングで、イベント名を改称し、他言語も含めて扱うようになった意図を教えていただけますか。
過去に比べ、今のディベロッパーはさまざまなテクノロジーを使い慣れていなければなりません。そして、Oracleがそういった多くの先端技術をサポートしているという事実を、皆さんに知っていただく必要があると考えました。我々もJavaに貢献する企業の1社ですが、だからといってJavaだけを扱えばよいと考えているわけではない、ということを伝えたかったのです。
ですので、これまで扱っていたJavaのコンテンツだけでなく、他のコンテンツや情報を追加するという今回のイベント形式となりました。もちろんJavaについても、我々のチームは当然のこと、OpenJDKを含めたさまざまなチームからも多くのコンテンツが提供されています。
――その記念すべき第一回であるOracle Code Oneの内容ですが、キーノートの狙いについて教えてください。過去のJavaOneキーノートでは、2016年の火星探査に関するトークに代表されるような、壮大なテーマに関する紹介もありました。それに対し今回は「変更されたリリースモデルのおさらい」、そして「進行中の各プロジェクトの詳細説明」という極めて地に足の着いた内容でしたが、このように構成した意図は何でしょうか。
Javaユーザーにとって、今年はまだリリースモデルの変更に対する「移行期」であると位置づけています。昔のモデルでは、2年から4年に一度、大きなサイズのものをリリースするというバージョンアップを行ってきました。しかしこれからは、6か月に一度、継続的に小さいバージョンアップを提供することで、ディベロッパーに対してイノベーションを提供するモデルに変わります。この変更により、どのような機会や課題が皆さんを含めた我々に生まれるのか、その理解をJava関係者全員で共有したい。それが、リリースサイクルや各プロジェクトの詳細を盛り込んだ意図です。
また、実際にユーザーの方々からの質問で最も多いのがリリースモデルに関する内容でもあったので、変更の詳細や、それを踏まえた言語の進化状況についてしっかりとした答えを示すことで、Javaの将来に対する安心感を得てほしいと考えていました。
結局のところ、このリリースモデルの変更は仕組みの話に過ぎないものですが、そこを改善することで、Javaはより速く、多くの人をテクニカルイノベーションに取り込んでいけると考えています。おそらく、あと1年も経てば人々もこの新しい仕組みに理解を示して下さるでしょうから、その頃にはより大きなテーマを選定したセッション内容にしていきたいと思っています。
Java 8を使い続けてもよいのか、次のバージョンへアップデートすべきなのか
――Java 11が9月末にリリースされました。リリースモデル変更後の初のLTS（Long Term Support）対象でもあり、期待の大きいバージョンであると思います。実際にリリースまでこぎつけた今、手ごたえや、世間の評判はどうでしょうか。
Java 11で出てきた多くのフィーチャーに、たくさんの人が興奮して下さっています。TLS 1.3[1]のサポートは熱狂して受け入れていただけましたし、新しいHTTPクライアント[2]もかなり高く評価いただいています。ヒープサイズの大きいアプリを扱うユーザーにとっては、ZGC[3]が一番人気かもしれません。他には、これまでクローズドなソースとしてOracleが保有していたJFR/JMC[4]をOpenJDKへ提供しましたが、これらも大変好評です。
また、11で出てきたフィーチャーだけでなく、9や10でリリースされたフィーチャーにも、多くの方が喜んで下さっていました。ローカル変数型推論[5]を活用した実装の簡素化も可能ですし、jlink[6]を使ってカスタムランタイムを作成すればアプリケーションのフットプリントを下げることができます。移行期である今、11の登場により8から多くの方が移行し、9以降の新たなフィーチャーが活用されることを我々は期待しています。
LTSである11では商用サポートのサブスクリプションを用意していますので、さらにバージョンアップを続けて最新のイノベーションにアクセスしていく使い方と、堅実なLTSバージョンを本番環境で走らせ続けるという使い方、ユーザーの皆さまはその両方をうまく組み合わせることができます。
注
[1] TLS（Transport Layer Security） 1.3：インターネット技術の標準化団体IETF（Internet Engineering Task Force）が策定するインターネット通信の暗号化技術の最新バージョン。前バージョンに比べ安全性やパフォーマンスに優れる。
[2] 新しいHTTPクライアント：Java 9、10でIncubatorモジュール（正式でないモジュール名およびパッケージにて実験的に提供される育成中モジュール）として実装されていた機能で、11にてjava.net.httpパッケージに正式追加されたもの。HTTP/1.1及びHTTP/2をサポートしており、同期／非同期プログラミングモデルもその両方をサポートする。
[3] ZGC（Z Garbage Collector）：新しいガベージコレクタ（メモリ管理技術）で、ヒープメモリに最大数テラバイトという巨大なサイズを想定し、かつGCの停止時間を10ms以下に抑えるという設計思想を持つ。
[4] JFR/JMC（Java Flight Recorder/Java Mission Control）：アプリケーションの稼働状況を記録し（JFR）、ヒープ使用量やCPU使用率などをGUIで確認できる（JMC）モニタリングツール。これまではOracleから有償で提供されていた。
[5] ローカル変数型推論：Java 10から追加された、変数の宣言時に型名の代わりに“var”と書くことで代替できる仕様。使い方により冗長な実装を簡素化できるなどのメリットがあるとされる。
[6] jlink（Java Linker）：Java 9から正式に追加されたツール。依存するモジュールのみを持つ軽量なカスタムランタイムイメージを作成できる。
――商用サポートに関する注目度の高い点として、Java 8のサポート期間の長さが挙げられます。Java 11の次のLTSバージョンであるJava 17のリリースは2021年を予定していますが、Java 8のサポートはそれ以上に続く見込みです。ユーザーにとってありがたい反面、腰の重い日本企業はJava 11をスキップして17まで待つところも出てくるのではと予測されています。そのような使い方は、現在のリリースモデルにおいて問題ないのでしょうか？
LTSバージョンはかなり長期間のサポートを想定しており、Java 8であれば少なくとも2025年まではサポートを継続します。つまり、それぞれのユーザーの方にとって適正な時期にバージョン移行できるようにしているのです。
その上で私がお伝えしたいアドバイスとしては、新しいバージョンが出たときは、評価利用や新機能のチェックにトライしていただきたいということです。どのような能力が備わっているか、新バージョンを実際に見てみていただきたい。それによって、組織にとってだけではなく、自分たちのアプリケーションにとって、いつバージョン移行するのがよいかという正しい判断ができるでしょう。
また、それはLTSバージョンのみに対し行うのではなく、6か月ごとの機能リリースでも実施いただくことをお勧めします。各バージョンの変更量が比較的少ないため、そのつどトライアルしておけば、次のLTSへの移行がスムーズにしやすくなるためです。
なお、LTSと非LTSで開発姿勢に違いはありませんし、後方互換性もあるようにしていますので、その点はご安心ください。もしも互換性に影響する変更がある場合、事前にそれを連絡し、ユーザーの方々が準備できるようにします。
――ではバージョンアップの追従について確認させてください。リリースモデルの変更後にあったバージョンアップでは、非LTSであるJava 9や10についてはあくまで開発やテストまでの活用に留め、本番移行はしなかったユーザーが多い印象でした。この先の非LTSであるJava 12や13に対して、我々はどのように関わっていくべきでしょうか。これらもテスト程度の使用に留めるべきでしょうか。
アプリケーションと、そして組織によって異なると考えています。いわゆるトラディショナルなアプリケーションであれば、長いスパンで開発、テストを実施し、やっと本番環境にリリースするというプロセスに慣れていると思います。そういった企業はおっしゃるように、Java 12や13をテストのみに使用し、次のLTSで本番に移行するという考え方が適用できるでしょう。
一方で、クラウド環境に馴染んでいるようなモダンなディベロッパーは、新しいバージョンのソフトウェアを使うことに慣れています。自分で試してみて、その結果が良ければ本番に使うという作業をいとわない、いわゆるDevOpsなどの比較的新しい開発スタイルにフィットする人たちです。
私たちが目標としているのはその両方のモデルをサポートしていくことです。そして、どう使うことが適正かは、お客様の選択に委ねたいと考えています。その上で、私たちの観点として言わせていただくと、非LTSとして今後リリースされるJava 12や13というバージョンも、本番使用に耐えうる品質を備えたものになるよう進めています。
ただし、非LTSを本番使用する場合、サポート期間は6か月ですので、その次のLTSまで継続的に6か月ごとのバージョン移行を行う必要がある点はご認識ください。
