Eclipse FoudationのエグゼプティブディレクタであるMike Milinkovich氏が先日のJAXカンファレンスで、Jakarta EEのための新たなEclipseのガバナンスモデルとロードマップを紹介した。少し前に世界的規模で実施された1,800人Java開発者を対象とした調査に基づき、新たなガバナンスモデルではマイクロサービス、クラウドネイティブなアプリケーション開発、リリースサイクルの短期化に焦点が当てられる予定だ。
“The Future of Java Innovation”と題されたセッションで氏は、新たなJakarta EE Webサイトを飾るであろう、待望のJakarta EEロゴも新たに公開した。
Jakarta EEの開発者調査では、3つの重要領域が定義されていた。
- マイクロサービスのサポート強化
- KubernetesやDockerなどとのネイティブな統合
- イノベーションの速度向上
Milinkovich氏は先日、Jakarta EEの将来についてInfoQに話してくれた。調査の結果については、次のように述べている。
コミュニティによって私たちに提示されただけでなく、私たちの共感も大いに呼び起こしてくれたこれらの目標を実現する上で、現在のこの状況は、開発者が私たちに対して望んでいたであろう、理想的なもののひとつです。その輪の中に加わっていることが、私たちにもはっきりと分かりました。
Milinkovich氏は言う。
まず最初に行うのは、Java EEのすべてをEclipse Foundationに移動し、Jakarta EEブランドの下で名称を変更する作業です。Java EEは今後も存続し、現行バージョンのレベルでサポートが続けられる予定ですが、以降の開発はすべてJakarta EEブランドの下で行われます。
Fortune 1000のすべての企業が、自社インフラのどこかの部分でJava EEを使用していますし、世界中には数百万というJava EE開発者がいます。非常に重要な技術プラットフォームであり、企業システムの多くの割合を占めているのです。
Milinkovich氏は昨年の秋、OracleがJava EEの所有権をEclipse Foundationに譲渡した後の自身の経験を振り返り､今後の方向性について次のように述べた。
まさにこれは、長い旅の始まりです。最終的には40に上る新たなプロジェクトに、大雑把に言って300人程のEclipseプロジェクトのコミッタが参加することになると予想しています。Java EEのすべての提供物をJakarta EEの下で名称変更するという、膨大な作業になります。
この作業を進めるため、Jakarta EEワーキンググループを立ち上げて、この活動のガバナンスを確立する計画です。現在はこの領域でのJCPの役割を引き継ぐための、まったく新しい仕様プロセスを確立する段階にあります。この作業も非常に大きなものになるでしょう。Jakarta EEのブランドコンプライアンスプログラムを作り上げる作業も残っていますが、本当によいスタートを切れたと思っています。
InfoQ: プレスリリースには、“Jakarta EEのコードベースを管理するEclipseのトップレベルプロジェクトでは、すでに年内2回のリリースを確約している”、とありました。これらのリリースのスケジュールはありますか？
Milinkovich: それに関しては、少し複雑な事情があります。私たちがコミットしたのは、今年Eclipseに移行した技術プロジェクトの２つのリリースについてなのです。これらはそれぞれ、GlassFish 5.1と5.2という名称になる予定です。Eclipse GlassFish 5.1は、Eclipse Foundationに移行したプロジェクトが公開する初のリリースとして、プロジェクトの今後の活動における重要なマイルストンになります。このリリースは、オリジナルのJava EE TCKを使用して、Java EE互換として認定されます。その後はできる限り早く、Java EE 8互換となる予定の5.2リリースに取り掛かるつもりです。
ですから、Jakarta EEの最初のバージョンの仕様はJava Eの仕様と同レベルになります。現時点ではまったく同じか、あるいはそれに近いものになる見込みです。これは移植作業の一部分ですが、私たちとしては、できる限りの自由度は維持したいと思っています。
Jakarta EE 8互換とブランドされたリリースを公開する上で重要なのは、仕様プロセスを完全に実施し、認定プログラムと、その認定プログラムを実施するための法的合意書を取得することにあります。
InfoQ: 具体的なスケジュールはありますか？
Milinkovich: Eclipse GlassFish 5.1は第３四半期末、Jakarta EE 8認定されるEclipse GlassFish 5.2は年末を予定しています。
InfoQ: 最新の事業計画にも含まれていましたね。
Milinkovich: そうですね、一番新しいバッチ計画にGlassFishが含まれていて、もう間もなくです。コメントされることは少ないのですが、実際には重要なものとして、TCKを全面的にオープンソースにする事業計画があります。TCKがすべてオープンソースになれば、かなり大きな意味を持つと思っています。
InfoQ: Jakarta EEはJava EE 8がベースなのでしょうか？
Milinkovich: オープンソースのものと、ブランドあるいは仕様ベースのものとの対比については、注意して考える必要があります。Jakarta EEはJava EEと同じ、特定のプログラムに付与されるブランド名です。ですから、例えばWebSphereがJava EE 8認定をうたうためには、Java EE 8のテストをパスしなければなりません。
これと同じことが、Jakarta EEという名称でも成立します。ただし、理解が必要なのは、これは単にEclipse Foundationからオープンソースコードが公開されるという意味だけではない、という点です。これにはプロプライエタリとしても、オープンソースとしても、Jakarta EEブランドの下で独立した実装を可能にする、という意味もあるのです。
ベンダからの公式な発表はありませんが、現時点ではWebLogicが、Jakarta EEのブランドの下で、Jakarta EE 8互換の認定を受けてリリースされるものと思います。WebSphereやJBoss、TomEEなどもこれに続くでしょう。
InfoQ: JavaEE、Jakarta EE、EE4Jという名称の間で混乱があるように思います。これらの違いについて説明して頂けますか？
Milinkovich: Java EEは、現在のJava EEを定義する一連の仕様です。この作業はJCP下で実施されたもので、現行のバージョンが長年にわたって続いていますから、基本的にはすでにメンテナンス段階にあると言ってよいでしょう。現時点でJava EEのユーザならば、この先何年間かは、ベンダがそのプラットフォームを保守してくれるはずです。
Jakarta EEは、今後発展する技術プラットフォームの名称になる予定です。このテクノロジの将来的なバージョンとその仕様は、Jakarta EEの名称とブランドの下でリリースされることになります。製品がJakarta EE互換であると認定するための、これまでと同様のプロセスを用意する予定です。一連のテストに合格する必要があります。今回の移行プロセスの一部として、Java EEのテストセットがOracleからEclipse Foundationに寄贈されていますので、これがテストの出発点になります。
EE4JはEclipse Foundationのトップレベルプロジェクトの名称で、関係するプロジェクトの大部分がこの下で運営されています。原則として、EE4Jを何らかの名称として使用することはほとんどありません。将来的にプロジェクト関係者は、自らをJakarta EE開発者として認識することになるでしょう。EE4Jは、Eclipse Foundationでプロジェクトを運用するための組織的なものに過ぎません。
GlassFishやJersey、Grizzly、JAX-RSなど、このテクノロジのリファレンス実装は、すべてがEE4Jトップレベルプロジェクトの下に置かれますが、EE4Jはブランドではありません。あくまでもトップレベルプロジェクトの名称に過ぎないのです。混乱の原因は、私たちがブランド名を選んでいなかったことにあります。そのために、唯一存在していたEE4Jという名称で呼ばれるようになったのです。
混乱しているのは残念ですが、やむを得ない部分もあります。今後時間が経てば、EE4Jという名前を聞くことはなくなるでしょう。
InfoQ: Oracleは今後もJava EEというブランドを持ち続けるのでしょうか？
Milinkovich: Java EEとJavaは、Oracleの所有する商標として残ります。Java EEという名称を使いたい場合は、その名称を使用できるのか、Oracleと話し合う必要があります。OracleがJava EEという名称をEclipse Foundationに譲渡していない点を意図的に取り上げて、Oracleに悪い印象を与えようとしている記事を目にしたことがあるかも知れません。
これについては、2つのことを指摘したいと思います。ひとつは、起こるべくして起こった状況である、ということです。JavaがOracleにとって重要なブランドであって、それを引き続き所有しようとするであろうことは、最初から分かっていました。大企業と商標についての知識が少しでもあれば、そうなることは理解できたはずです。
第2のポイントは、私たちが今回の名称変更を、このテクノロジにとって非常に肯定的な状況であり、大きなチャンスであると考えていることです。多くの開発者の心の中では、Java EEは常に変わらず、10年以上前のオンプレミスのアプリケーションサーバを意味しています。名称をJakarta EEにすることは、開発者がこのテクノロジに対して持つ印象を変えるチャンスなのです。ですから私は、今回の名称変更に期待しています。テクノロジのブランドを変えて、開発者の心の中での位置付けを変えることで、今後の前向きな展開が期待できると思っています。
InfoQ: 新たにクラウドネイティブを重視する上では、間違いなくよいスタートだ、ということですね。
Milinkovich: 正確には、クラウドネイティブとマイクロサービスを重視しています。近いうちにリアクティブも加わると思います。これらはいずれも、Jakartaを導入することですぐに手に入る、極めて重要なテクノロジです。1年後には、興味深い新技術であるという理由でJakarta EEに取り組もうとする開発者が現れることを期待していますし、それが実現すると強く信じています。
Java EEの新リリースであったならば、おそらく試してみようとは思わないでしょう。自分たちの問題解決には役立たないものだというイメージを、すでに持っているからです。ですから私は、今回の名称変更がコミュニティとテクノロジにとって大きなチャンスだ思うのです。
InfoQ: Java EE 8がメンテナンス限定モードになるということは、Oracleは今後Java EEの開発を行なわないということでしょうか？
Milinkovich: そうです。Java EE 9になることはありません。
InfoQ: PayaraやGlassFish、OpenLibertyなど、Java SE 9では動作しないアプリケーションが多数あります。ですが、この分野ではいくつかの動きがあります。例えば、Data GeekeyのJOOQをサポートするプロジェクトはすでにモジュール化されていますし、Speedmentは昨年からJava 9への移行プロセスを開始しています。Jakarta EEも将来的にはJava 9をサポートするのでしょうか？
Milinkovich: いつかの時点でサポートすることは間違いありません。Java EEのエコシステムが、Jigsawのメリットを活用できるようなコードのモジュール化を達成できていないことは明白ですから、必要な作業がたくさん残っています。
Javaエコシステム全体としては、新たなプラットフォームと言語の開発への取り組みを続けなければなりません。将来的にはそれが実現すると確信していますが、いつ、どのリリースで実現するかということは、私には分かりません。実行すべき重要なことはたくさんありますから、その中での位置を見つけ出さなくてはならないでしょう。
InfoQ: 現在の活動がJava 9サポートより優先されるというのは、当然だと思います。
Milinkovich: Java 9の導入状況も関係しています。前述の調査結果を見れば、Java 9、あるいは新たにリリースされたJava 10の導入例が、Java 8に比べて極端に少ないことが分かると思います。数年後になると思いますが、Java 8のサポートが終了すれば、もっと多くの動きが現れるでしょう。
現時点で存在するコードには、Jigsawやモジュール化を完全に受け入れるための開発作業が必要です。その作業量は膨大なので、必要に迫られるまでは先送りされることになるでしょう。
当面はツールやフレームワークが、それら自身を新たなJava上に移植しなければならないという圧力を受けることになるでしょう。ユーザや企業がさまざまなインフラストラクチャをすべて移行し始めた時の、IDEからログ機能に至るまで、Javaエコシステム全体のモジュール化への移行は膨大な作業になります。
InfoQ: Java EEとCORBAモジュール(JEP-320)がJDK 11から削除されたことは、Jakarta EEに何らかの影響があるでしょうか？
Milinkovich: Java EEがEclipse Foundationに移行するので、SEとEEは完璧に分離されていなくてはなりません。JTA仕様の一部がSEにリークしていますが、これも取り除かれているところです。他の作業と並行して、このようなクリーンアップ作業が舞台裏で行なわれています。
InfoQ: JDKが6ヶ月間のリリースサイクルを新たに採用しましたが、Jakarta EEも同じことをする必要はあるのでしょうか？
Milinkovich: まだ分かりません。これは私の個人的意見であって、コミュニティの技術的リーダの意見を反映するものではありませんが、Java SEが6ヶ月単位でリリースを行うということは、Jakarta EEも同じようにする理由にはならないと思っています。
イノベーションの速さやペースは、クラウドネイティブとマイクロサービスの導入やリアクティブの実装のために、何が必要かによって決まるものだと思います。これらのイノベーションの中で、Java SEプラットフォームの新機能に特別な結び付きのあるものは、それほど多くはないでしょう。私たちに相応しいリリースのリズムが見つかると思います。特に、企業が新しいバージョンのJavaに移行する割合は、SEのリリースサイクルよりもはるかに遅い、という理由もあります。
現時点では、SEがそうしているからという理由で、6ヶ月というリズムに縛られることに特別な価値はありません。ですが、まだ分かりません。6ヶ月毎に新しいバージョンのJavaには移行しないが、6ヶ月毎にリリースする、というシナリオも想定することは可能です。
企業やクラウドフレームワークが6ヶ月毎にJavaの最新バージョンに移行しないのであれば、Jakarta EEがそうする必要は何もなくなります。お断りしたように、これは私個人の意見です。プロジェクトを運営するスマートな技術者たちは、まったく違う観点を持っているかも知れません。ですから、まだ分からないのです。
InfoQ: Cloud Native Computing Foundationとの協力関係はありますか？
Milinkovich: 彼らとの協力関係を望んでいるのは確かです。IoTを構築するテクノロジの一部では、すでにCNCFとの協力関係を構築するプロセスにあります。私たちとしては、KubertenesやDockerエコシステム上で可能な限り強固なJakarta EEプラットフォームのフォームを確立することによって、両者からの要請に関する協力的な対話の下での共同作業を実現する、ということを目標に置いています。
Kubernetesが業界において大きな弾みをつけている今が、双方にとって大きなチャンスだと思います。Kubernetesがクラウドプロバイダ間のワークロードの移動に留まらず、オンプレミスのクラウドインフラストラクチャからパブリッククラウドインフラストラクチャへのワークロード移動も可能にすることで、デプロイメントの柔軟性が大きく向上するからです。
ですが、同時にJavaは、企業におけるナンバーワンの言語プラットフォームでもあります。ですから、私たちがこの２つのテクノロジを強く結び付けることができれば、企業に対するクラウド導入を促進するというだけでなく、文字通り何百万という技術者が付けているスキルを、この新しい技術分野へと導くための一助となると思っています。
InfoQ: Eclipse FoundationとCNCFが相互の組織のメンバになる必要がある、ということでしょうか？
Milinkovich: そうなるかも知れませんが、CNCFも私たちも課金型の組織ではありません。実際にはそうしてはいませんが、私たちの協力関係がよいものを生み出そうとしていることを両者が公表することは、素晴らしい意思表示だと思います。
リソース
- “The Relationship Between Jakarta EE, EE4J, and Java EE”、Ivar Grimstad (2018年3月26日)
- “Background on Oracle's Contribution to Jakarta EE”、Will Lyons (2018年4月24日)
- “The Road to Jakarta EE”、David Delabassee (2018年4月24日)
- “The Eclipse Foundation Has Established Jakarta EE Working Group”、 Fujitsu (2018年4月24日)
- “In Support of Jakarta EE's Quest to Accelerate Cloud Native Java”、Mark Brewer (2018年4月24日)
- “Jakarta EE - The New Home for Enterprise Java”、Ian Robinson (2018年4月24日)
- “Jakarta EE is Officially Out”、Mark Little (2018年4月24日)
- “The Future of Cloud-Native, Open Source Java with Jakarta EE”、Debbie Hoffman (2018年4月24日)
この記事を評価
- 編集者評
- 編集長アクション