X

A blog about Oracle Technology Network Japan

Java 14、Java 15、Java 16、およびそれ以降でのプレビュー機能の役割

Guest Author

※本記事は、David Delabasseeによる"The role of preview features in Java 14, Java 15, Java 16, and beyond"を翻訳したものです。


プレビュー、試験運用版、インキュベータ版の各機能について、オラクルが新しいJDKの機能性に関するフィードバックを集める仕組み

著者:David Delabassee
2020年6月8日

多くの人々が本番環境でJavaを使用して重要なワークロードを実行している今、Javaには世界的な影響力があります。その深さと広さを考えれば、新機能は明確かつ完全に設計されなければならないだけでなく、信頼性とメンテナンス性が高い形で実装されなければなりません。Java開発者が本番環境で使用するために提供される新機能は、すべて最高の品質を持ち合わせている必要があります。したがって、開発者に前もって新機能を使ってもらい、フィードバックを求めるという手続きが欠かせません。フィードバックは、機能の改善と、最終的な確定版として期待される品質レベルの実現に役立ちます。

未確定の新機能には、いくつかの分類があります。

  1. プレビュー版:Javaプラットフォームの新しい機能のうち、仕様が完全に作成され、完全に実装されているが、まだ調整の余地があるもの
  2. 試験運用版:主にHotSpot JVMの新機能
  3. インキュベータ版(インキュベータ・モジュール):新しいAPIやJDKツールになる可能性があるもの

さらに、これら3つの分類には当てはまらない未確定機能も存在しますが、それについては後ほど説明します。

オラクルは、プレビュー機能、試験運用版機能、インキュベータ・モジュールを活用してコミュニティからフィードバックを集め、その後に新機能をJavaプラットフォームの確定版機能としています。本記事では、この一連の作業がどこでどのように行われているかについて説明します。図1に、新機能の進展状況の例をいくつか示します。
 The evolution of three recent features
図1:最近の新機能3つの進展状況

ほぼすべての新機能は、JDK拡張提案(JEP)として始まります。JEPは、重要なJDK拡張を管理するための明確に定められた仕組みです。たとえば、次のようなものがあります。

  • Java言語仕様のJava言語機能(テキスト・ブロックやレコードなど)
  • コアJavaプラットフォームのJava SE API機能(java.lang.Object、java.lang.String、java.io.Fileなど):このようなAPI機能は、名前がjavaで始まるモジュールに含まれる
  • JDK固有機能が含まれるJDK API機能(JDK Flight Recorderなど):このようなAPI機能は、名前がjdkで始まるモジュールに含まれる
  • JDKツール機能(jshellやjlinkなど)
  • Java仮想マシンのOpenJDK実装であるHotSpot JVMの固有機能:ここには、アプリケーション・クラス・データ共有とZガベージ・コレクタ(ZGC)という2つの機能などが含まれる

これらの機能の関係を図2に示します。
 Where preview, experimental, and incubating features live
図2:プレビュー機能、試験運用版機能、インキュベータ版機能が存在する場所 

ところで、JDKについて話すとき、Java APIという用語はJava SE APIとJDK APIの両方を表す言葉として使われることが多くなっています。

それでは、重要性はどのように決まるのでしょうか。拡張が重要だと見なされるのは、需要が高い場合、JDKや、JDK自体が開発されるプロセスおよびインフラストラクチャに影響がある場合、あるいは単に多くのエンジニアリング作業が必要になる場合です。JEPのプロセスは、機能の非推奨化や既存機能の改善にも使われます。

ほどんどの大型機能は、JEPを使用する2段階のアプローチに従って導入されます。すなわち、事前アクセス・フェーズから始め、その後にアクティベーション・フェーズが続くという方式です。事前アクセス・フェーズは、1回で済むこともあれば、複数回繰り返されることもあります。その間、開発者は未確定の新機能を使用できます。事前アクセス・フェーズの期間(複数回設けられることもあります)中、開発者は積極的に未確定機能を使用し、その経験をもとにフィードバックを送ることが推奨されています。

提供されたフィードバックから改善の余地が明らかになった場合、その次の事前アクセス・フェーズで対処される可能性があります。このフィードバックは、新しい言語機能が扱われることが多い、プログラマー向けガイドや、新しいAPIのJavadocサンプル、FAQなどのドキュメントの改善に役立てられることもあります。

そして、新機能の準備が整ったと判断されたとき、最終フェーズに移り、そこで新機能がJavaプラットフォームの確定版機能となります。

新機能に取り組んでいるエンジニアがどんな種類のフィードバックを待っているかという点を踏まえて、期待されているフィードバックを知ることが重要です。このようなエンジニアは、開発者がどのように新機能を使用しているかということに主たる関心があります。たとえば、新機能を使用したときに技術的な問題や互換性の問題があるかどうか、新機能は既存機能と緊密に統合されるかどうか、コードをリファクタリングして新機能を使用することに支障があるかどうか、といった点です。

注:新機能に取り組んでいるエンジニアは、実のところ、別のアイデアや、部分的に関連している問題のソリューション候補を探しているわけではありません。また、その機能に関連する要望を探しているわけでもありません。なぜでしょうか。そのような提案は、Javaプラットフォーム全体のビジョンを無視した、短期的で限定的なメリットを求めるものであることがほとんどだからです(実際に機能を使ってみることさえせず、単なる反対や、どのみち役に立たない提案を行いたいという人からのフィードバックには、特にそのような傾向があります)。

それでは、フィードバックを送るべきなのは、どのような人でしょうか。エンジニアたちが歓迎しているのは、Java開発者からのフィードバック(新しいAPIに関するものなど)やツールのベンダーからのフィードバック(新しいJDKツールに関するものなど)です。究極的には、建設的で今後の行動につながるフィードバックならすべて歓迎です。

ところで、フィードバックは、使用を求められている手段で送ることが重要です。ソーシャル・ネットワークに投稿されたコメントが検討される可能性はほとんどありません。そのため、各JEPでは、フィードバックを集めるためのメーリング・リストを明示しています。たとえば、JEP 359では、amber-devメーリング・リストにフィードバックを送ることを求めています。

要するに、Javaエンジニアたちは、早い段階で未確定版の新機能を使ってもらうことで、新機能について、実際に使用した経験の報告や、その後の行動につながるフィードバックを求め、必要な調整を行っています。その後、新機能は最終的な確定版としてJavaプラットフォームに組み込まれます。

 

プレビュー機能

Java言語機能とJava SE API機能はとても広く使われているため、設計にミスがあれば否定的な結果につながってしまいます。そのようなリスクを避けるため、あるJEP(JEP 12)で、新しいJava言語およびJava SE API機能のプレビューを行えるようにすることが提案されました。プレビュー機能とは、仕様が完全に作成され、完全に実装されていると考えられるものの、Javaプラットフォームに最終的な確定版として組み込まれる前に変更される可能性があるものを指します。収集されたフィードバックは、評価を経た後、機能が確定版になる前に最終の調整を行うために使用されます。

たとえば、Project Amberは、Java言語を進化させることで開発者の生産性向上を目指すOpenJDKプロジェクトです。Amberでは、プレビュー機能の仕組みを活用して、標準の確定版機能をJavaプラットフォームに少しずつ導入しています。Amberの新機能が確定版になる前に、その後の行動につながるフィードバックを集めるためには、2回のプレビュー・ラウンドが妥当と考えられることがわかります(図3参照)。
 Project Amber features delivered as of Java 15
図3:Java15時点で提供されている、Project Amberの機能 

さらに詳しく見てみるために、switchについて考えてみます。switch式はProject Amberで開発され、Java 12(JEP 325)とJava 13(JEP 354)でプレビューが行われ、Java 14(JEP 361)で標準の言語機能になりました。

Java 12では、switch式の値を生成するためにbreakキーワードが使われていました(例:break 42;)。しかし、フィードバックからこのようなbreakの使い方はわかりにくいという可能性が浮上したため、Java 13では、同じことをするためにyieldキーワードが導入されました(例:yield 42;)。

確定版のswitch式(Java 14)では、Java 13においてプレビューが行われたyieldのアプローチがそのまま使用されています。プレビュー機能は確定版に非常に近いものとして作られていますが、オラクルはプレビュー版の間で変更を行う権利を持っています。たとえば、Java 12のプレビュー機能でのbreak 42;をJava 13のプレビュー機能でのyield 42;に変えるような変更です。長期互換性のルールに従うのは、Java 13のyieldを引き継いだ確定版、つまりJava 14のswitch式だけです。

 

試験運用版機能

試験運用版機能は、HotSpotの重要な拡張についてのフィードバックを集めるための試験台として使用される仕組みです。プレビュー機能でのJEP 12とは異なり、試験運用版機能について定めたJEPはありません。試験運用版機能のプロセスは、公式なプロセスというよりは、HotSpotの慣習として確立されたものです。

例として、Zガベージ・コレクタを取り上げます。ZGCは低遅延ガベージ・コレクションであり、一時停止時間は10ミリ秒未満、通常は2ミリ秒程度です。さらに、数メガバイトという小さなものから、数テラバイトという大きなものまで、ヒープ・サイズによらないという特徴もあります。

ZGCチームは、試験運用版機能の仕組みを複数回活用しました。最初のZGCは、JDK 11でLinux x64限定の試験運用版機能として導入されました(JEP 333)。それ以降、ZGCに改善が追加されました(同時クラス・アンロード、メモリの返却、プラットフォームの追加など)が、一方で削除されたZGC機能もありました。

試験運用版機能の仕組みを複数回使用して得られたフィードバックや使用報告すべてにより、ZGCを徐々に改善することができました。現在では、HotSpot機能に期待される高品質を備えるようになっています。その結果、現在、JEP 377で、ZGCをJDK 15の正式なHotSpot本番環境向け機能とする提案が行われています。

 

インキュベータ・モジュール

JEP 11でインキュベーションという概念が導入されています。今後改善や安定化が行われてから将来的にJava SEプラットフォームまたはJDKの一部としてサポートされる可能性がある、JDK APIおよびJDKツールをインキュベーションの対象に含めることができます。たとえば、HTTP/2 Client APIは、JEP 110によってJDK 9およびJDK 10でJDK固有のAPIとしてインキュベーションが行われてきました。最終的にはインキュベーション・フェーズを抜けて、Java 11で標準Java SE APIの一部となりました(JEP 321)。

 

未確定機能の使用

開発者が意図せず未確定機能を使ってしまうことがないように、重要な予防策が導入されています。この対策が必要なのは、未確定機能が後のJavaフィーチャー・リリースで最終的な確定版になる際に、変更される可能性があるためです。さらに、Javaの厳密な下位互換性ルールの対象になるのは、最終的な確定版機能のみです。

そのため、意図せずに使用されることがないように、プレビュー機能と試験運用版機能は、デフォルトでは無効になっています。また、JDKドキュメントでも、こういった機能やその関連APIは未確定であることが開発者に対して明確に警告されています。

プレビュー機能は特定のJava SEフィーチャー・リリースに固有です。プレビュー機能を使うためには、コンパイル時と実行時に特殊なフラグを指定する必要があります。あるJava SEプラットフォーム・リリース(たとえばJava 14)でjavac --enable-preview --release 14 ...と指定することにより、プレビュー機能を使用したクラス・ファイルをJavaコンパイラで生成できます。その際、コンパイラはプレビュー機能が使われていることを開発者に警告します。同様に、java --enable-preview ...と指定することにより、対応するJVM(この場合はバージョン14)でクラスを実行できます。また、jshell --enable-previewと指定することにより、対応するバージョンのjshellでプレビュー機能を使用できます。

ほとんどのIDEではプレビュー機能の使用に対応しています。そのため、開発者がお気に入りのIDEでプレビュー機能を使用できるだけでなく、プレビュー機能が最終的な確定版になってから短時間でIDEが対応するようになっています。たとえばIntelliJ IDEA 2020.1では、"Project"と"Modules"の設定で"Project language level"を"14"から"14 (Preview) - Records, patterns, text blocks"に切り替えるだけで、JDK 14のプレビュー機能を有効化することができます。

ところで、未確定機能が必要なアーティファクトは配布するべきではありません。たとえば、プレビュー機能を利用したアーティファクトをMaven Centralで配布することは避けてください。このようなアーティファクトは、特定のJavaフィーチャー・リリースでしか実行できないからです。

試験運用版機能は、JVM機能であり、デフォルトでは無効になっています。HotSpotで試験運用版機能を使用できるようにするためには、-XX:+UnlockExperimentalVMOptionsフラグを指定します。そして実際の試験運用版機能は、固有のフラグを追加指定して有効化することができます。たとえばZGCの場合、-XX:+UseZGCとします。

さらに、インキュベータ・モジュールも、意図せずに使用されることがないように保護されています。インキュベーションを行えるのは、jdk.incubatorネームスペースのみであるため、クラスパス上のアプリケーションでは、--add-modulesコマンドライン・オプションを使って明示的にインキュベータ版機能の要求を解決する必要があります。一方、モジュールを使用するアプリケーションでは、インキュベータ版機能に対して直接requiresまたはrequires transitive依存性を指定する必要があります。

 

補足:早期アクセス・ビルドについて

OpenJDKの長期プロジェクトには、LoomPanamaValhallaといったものがあります。これらのプロジェクトの目的は、Javaプラットフォームの特定の部分に対して思い切った改善(または完全な再構築)を行うために、個別の領域について基本的な調査をすることにあります。たとえば、Loomの目的は、スレッドを軽量化して使いやすくすることで、Javaプラットフォームの同時実行性を大幅に向上させる点にあります。

これらのプロジェクトで扱う範囲が広大であることを考えれば、いくつかのJavaフィーチャー・リリースにわたって複数の機能が提供され、それらの機能全体によって、取り組みの対象となっている領域に対処することになるでしょう。これを実現するために、さまざまな調査が行われ、可能性のあるソリューションを試すために各種のプロトタイプが開発されることになります。その中には、断念されるアプローチや再考されるアプローチも出てくるかもしれません。

この作業に多くの時間やエンジニアリング作業が必要になることは、言うまでもありません。これらのプロジェクトのもとで開発される新機能は、まったく完成しておらず、安定性が見込めるものでもないため、フィードバックを求める通常の仕組みを活用することはできません。しかし、使用に関するフィードバックに価値がないというわけではありません。それどころか場合によっては、早期のフィードバックによって、設計上の検討事項の一部が明らかになることや、初期プロトタイプが検証されることもあります。

早い段階でそのようなフィードバックを集めるため、設計段階や開発段階で新機能の早期アクセス・ビルドが個別に提供される場合もあります。このような機能固有の早期アクセス(EA)JDKビルドは時々行われますが、その目的は、エキスパート・ユーザーに早い段階で特定の新機能を試してもらうことに限定されています。

EAビルドの対象は高いスキルを持つユーザーに限定されているため、プロジェクト・リードが一部のルールを緩和する(たとえば、互換性に関連すること)ことや、制約を課す(たとえば、新機能の一部を実装しないでおく)こともできます。たとえば、最初のLoom EAビルドは2019年7月に、2回目のEAビルドはその6か月後に登場しました。この2回目のビルドは、プロジェクト・リードの言葉によれば、「最初のEAビルドのAPIとはかなりかけ離れている」ものでした。これは、早期アクセス機能がいかなる互換性ルールの影響も受けないことを実証しています。この点からも、EAビルドはエキスパート・ユーザーが個々のEAビルドの対象範囲内で新機能を試すためだけに使うべきであることが再確認されます。

EA JDKビルドは、jdk.java.netで公開されています。ダウンロード・ページには、EAビルドの対象範囲が示され、制限や既知の問題が記載されています。さらに、フィードバックを提供するためのメーリング・リストも指定されています。このようなフィードバックや使用報告は、今後行われる、新機能の再構築や改善に役立てられます。機能の安定性と品質が期待されるレベルに達すると、JEP(フィードバックの仕組みがある場合もない場合もあります)などの通常の仕組みを活用できるようになります。その最終的な目的は、Javaプラットフォームの確定版機能になることです。

 

まとめ

JavaプラットフォームやJDK、HotSpotの新機能に設計的な欠陥があれば、重大な影響を生むことになります。そのような欠陥を避けるため、オラクルはプレビュー機能、試験運用版機能、インキュベータ・モジュールという複数の仕組みを使い、開発者が前もって未確定版の機能を使用できるようにしています。

多くのJava開発者の手に渡って本番環境で使用される機能には、品質の高さが求められます。この高品質の実現に貢献しているのが、年2回のリリース周期、Javaコミュニティによるサポート、そして未確定機能のフィードバック・ループなのです。

本記事の執筆に協力いただいたJavaプラットフォーム・グループのAlex Buckley氏、Donald Smith氏、Dalibor Topic氏に感謝いたします。


David Delabassee

オラクルのJavaプラットフォーム・グループに所属するデベロッパー・アドボケート。それ以前は、Oracle Serverlessイニシアチブを担当していた。Java EE 8と、Jakarta EEイニシアチブの一環としてのEclipse Foundationへのその移管にも深く関与。 大小のカンファレンスやユーザー・グループでの講演など、世界各地で何年にもわたってJavaの普及に努める。https://delabassee.comのブログに加え、さまざまなメディアで技術記事を多数執筆している。 ベルギー在住。Twitterのフォローは@delabasseeから。

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.