狠狠撸

COPYRIGHT (C) 2020, ECLIPSE FOUNDATION, INC. | MADE AVAILABLE UNDER THE ECLIPSE PUBLIC LICENSE 2.0 (EPL-2.0) 1
テクニカルオーバービュー
Jakarta EE WG ステアリング委員
数村憲治 @kkzr
2020/02/26

COPYRIGHT (C) 2020, ECLIPSE FOUNDATION, INC. | MADE AVAILABLE UNDER THE ECLIPSE PUBLIC LICENSE 2.0 (EPL-2.0)
AGENDA
2
Jakarta EE 8 までの振返り
Jakarta EE 9 に向けて
Jakarta EE と MicroProfile
最後に

Jakarta EE 8 までの振返り

4COPYRIGHT (C) 2020, ECLIPSE FOUNDATION, INC. | MADE AVAILABLE UNDER THE ECLIPSE PUBLIC LICENSE 2.0 (EPL-2.0) 4
Javaの歴史
202020152010200520001995
リリース間隔
JDK1.0
J2EE1.2
J2EE1.3 J2EE1.4
JavaEE5
JavaEE6
JavaEE7
JavaEE8
Jakarta EE 8
JDK1.1
JCP設立
MicroProfile
JakartaEE

Java史上最大の転機
2017年９月、Java EE テクノロジーはEclipse Foundation
に移管以降、Jakarta EEというブランドで進化続けている

Java EE は、いたるところで稼働
世界の
Java 開発者
のFortune
500社がJava
EEを使っている
の会社が、
アプリケーションの
80%以上をJava
で作っている
Sources: InfoWorld, 2018 Jakarta EE Developer Survey

Java EE を使っている理由トップ 3
Sources: InfoWorld, 2018 Jakarta EE Developer Survey

> クラウドネイティブ
> マルチクラウド
> 迅速なイノベーション
> 投資保護
> オープンな仕様作成プロセス
> ビジネスリスクの緩和
> 開発の最新化
Jakarta EE の優先度

Jakarta EE Working Group, an
industry consortium
技術ロードマップ作成互換性確認
Jakarta EE ブランド周知
仕様承認
コミュニティ形成
ワーキンググループ
業界をリードしていく団体

Jakarta EE
Working Group
?ベンダー中心
?ガバナンス?予算
?仕様承認
?マーケティング?ブランド
EE4J
(Eclipse Enterprise for Java)
?開発者中心
?オープンソースコード/TCK
?仕様作成
?アジャイル?イノベーション

JAKARTA EE
Fully Open Source Cloud Native Java
2019 Duke’s Choice
Award Winner
> エンタープライズ向けJava技術の
進化とイノベーションをオープンで
ベンダー中立なプロセスで実現
> FullとWebプロファイル仕様、互換
テストセット(TCK)、互換実装を、
オープンソースで提供。

２０１９年９月１０日、Java団体と開発者をリードする
コミュニティによって、エンタープライズ向けJavaの新しいベースを
オープンでベンダー中立なプロセスによってリリース。
Jakarta EE 8 提供物
Java EE? 8に
完全互換
オープンな仕様
オープンソースTCK
ライセンスとプロセス
複数の互換実装
Java EE 8と
同等の統合
透明性のある
ブランドプロセス
Jakarta EE 8: Powered by Participation

> Jakarta EE 8 は、 Java EE 8の仕様と互換テスト
(TCK)において、完全互換
javax名前空間と同じAPIとJavadocを使用
Java EE 8で規定された動作と同じ
javax APIを使ったJava EE 8アプリケーションは変更
不要でJakarta EE 8で動作可能
Java EE 8のTCKをパスした実装は、Jakarta EE 8
のTCKもパスする
Java EE 8 完全互換

14COPYRIGHT (C) 2020, ECLIPSE FOUNDATION, INC. | MADE AVAILABLE UNDER THE ECLIPSE PUBLIC LICENSE 2.0 (EPL-2.0)
14
Jakarta EE Specification Process
コードファースト開発を実現するオープンソース仕様プロセス
Java EEに対するJCPの後継

仕様が先
(Specification First)
コードが先
(Code First)
スペックリード主導共同作業
標準となる1つだけの参照実装
(Reference Impl)
1つ以上の互換実装
(Compatible Impl)
Oracleによる互換認証プロセス自己認証プロセス
ドキュメントとTCKは、
クローズドソース
ドキュメントとTCKは、
オープンソース

透明性
> Jakarta EE 互換実装製品に対するオープンな
認証プロセス
> これまでより低コストでゆるやかなJakarta EE商標ライセンス
> たくさんの技術提供者が、エンタープライズJavaコミュニティの
中でJakarta EEブランドをけん引
オープンソース TCK ライセンスとプロセス
オープン負荷分散ベンダー中立
と継続性

互換実装
17
> Jakarta EE 8 (Full/Webプロファイル)互換実装:
リリースと同時に, Eclipse GlassFish, Open Liberty
(IBM), and WildFly (Red Hat) が互換実装として認定
Fujitsu, Oracle, Payara, Red Hat, Tomitribe, その他の
Jakarta EE ワーキンググループメンバーの製品もJakarta EE 8
互換実装製品の提供を予定
Java EE 8 互換製品は Jakarta EE 8 互換

Strategic Members
Participating Members
Java 業界リーダーによるサポート

Jakarta EE 9 に向けて

本日お話しすることには
未確定事項が含まれています。

> 安定性と互換性
> イノベーションに対してオープン
> Jakarta EE TCKの分割
> JPMS
> 標準的なMavenビルドシステム
> 古い技術の非推奨
> リリース期間の短縮
> テストにフォーカス
> 仕様とドキュメントの標準化
技術的方向性

Java EE 8GlassFish 5.0
Java EE 8Eclipse GlassFish 5.1
Jakarta EE 8Eclipse GlassFish 5.1
Jakarta EE 9Eclipse GlassFish 6.0
● 新しい名前空間
● Java SE 11
● 古い仕様の削除
Jakarta EE と GlassFish
....
● javax 名前空間
● 新しいプロセス
● 新しいライセンス
● 新しいロゴ

23COPYRIGHT (C) 2020, ECLIPSE FOUNDATION, INC. | MADE AVAILABLE UNDER THE ECLIPSE PUBLIC LICENSE 2.0 (EPL-2.0) 23COPYRIGHT (C) 2019, ECLIPSE FOUNDATION, INC. | MADE AVAILABLE UNDER THE ECLIPSE PUBLIC LICENSE 2.0 (EPL-2.0) 23
> CDI Alignment
> Modularity
> MicroProfile, Microservices
> Cloud native deployments
> Reactive streams
> Java 11
Jakarta EE 9 希望リスト

プラットフォームプロジェクト
各仕様プロジェクト
方向性の決定
プランの作成
仕様の作成
Jakarta EEワーキンググループ
EE4Jプロジェクト
Jakarta EE 9 役割
承認
仕様委員会委任
ステコミ(Steering Committee)

https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan
機能はJakarta EE 8に同じ
名前空間を「jakarta.*」に変更
古いAPIの削除?オプション化
Jakarta EE 9リリースプラン

ツールベンダーは、新しい「jakarta.*」名前空間に対応
開発者は、アプリが新しい名前空間に移行できるか検証
ランタイムベンダーは、Jakarta EE 8互換サポート機能
の検証
Jakarta EE 10で加速するための基礎作り
26
ツーリングリリース

APIパッケージ名のトップレベルをjavaxからjakartaに変更
javaxは、APIを変更しない場合に限って使用可能
この制約により、Jakarta EE 8では機能追加がなかった
Jakarta EEに機能追加するためには、javaxを使わない
ビッグバン v.s. インクリメンタル
ビッグバン: すべてのAPIパッケージが対象
インクリメンタル: 機能追加するものだけが対象
名前空間の変更
採用

Jakarta EE 8/Java EE 8以前のアプリは動くのか？
名前空間の変更による影響
?
バイナリ互換ソース互換
ランタイム製品による対応 IDE他ツールによる対応
実装製品は実行時に
パッケージ名を変換する
仕組みを提供することを推奨
Jakarta EE 8ビルド環境を
使用するか、jakarta名前
空間へのソース変更

Jakarta EE 8仕様で作成したアプリケーション(バイナリ)を、
Jakarta EE 9ランタイムで動かしたい。
製品が提供するバイナリ互換機能により、そのまま動作可能
変更するソースはJakarta EE 10のAPI jarを使い、
変更しないソースはJakarta EE 8のAPI jarを使いビルド
Jakarta EE 8仕様で作成したアプリケーションを、
Jakarta EE 10の機能を一部使って変更。
(すべてJakarta EE 10のAPI jarでビルドも可)
名前空間の変更 – ケーススタディ

各APIはJava SE 8ソースレベルでコンパイル
Java SE 8での動作は任意
30
Java SE バージョン
WebプロファイルとFullプロファイルの互換実装は、
Java SE 11で動作しなければならない

各仕様のバージョンは、メジャー番号を上げる
例: JPA 2.x → 3.0
機能追加はないけど、名前空間の変更のため
Maven artifact なども
仕様バージョン

Jakarta XML Registries
Jakarta XML RPC
Jakarta Deployment
Jakarta Management
(注) Optional Features でない方
Jakarta Stable API プロジェクト仕様
Support for Distributed Interoperability
Jakarta Enterprise Beans Core Contracts and
Requirements (注)
Jakarta EE 9 で削除される仕様 (pruning)

Java SE 11での削除機能だがリリースプランに明確な記載なし
RMI-IIOPは必要か？
削除されるEJB InteroperabilityはRMI-IIOPに依存
EJBリモートは削除されないので
ORBが必要かどうかはEJBリモートの実装しだい
例：WebLogicはT3プロトコルも提供
RMI-IIOP

仕様からの削除
古いAPIを仕様から削除することで、
新規参入障壁を軽減
仕様から削除された仕様を製品として
提供するかはベンダー次第
Pruning
提供されない

Jakarta Activation (必須)
Jakarta XML Binding (オプショナル)
Jakarta XML Web Services (オプショナル)
Jakarta Web Services Metadata (オプショナル)
Jakarta SOAP with Attachments (オプショナル)
これらのAPIも、javax から jakarta パッケージに変更
Java SE 8から追加されるAPI

各APIは、複雑な依存関係
８段階に分けて提供
依存されているAPI
Maven CentralへRC版を登録
依存しているAPI
Maven Centralに登録されている
RC版を使ってビルド
繰り返し
Jakarta EE 9 Waves

Jakarta EE 依存関係 https://www.eclipse.org/lists/jakartaee-spec-project-leads/png5VaauMN_LW.png

Jakarta EE 9 Waves
依存関係なし
Web Services Metadata
Messaging
Concurrency
Persistence
Annotations
Managed Beans
Wave 1
Servlet
Expression Language
Dependency Injection
Bean Validation
JSON Processing
WebSocket
SAOAP with Attachments
Activation
Interceptors

Jakarta EE 9 Waves
Wave ２
XML Binding
JSON Binding
Authentication
Server Pages
Mail
Debugging Support
for Other Languages
Wave 3
XML Web Services
Contexts and
Dependency Injection
Wave 4
Transactions
RESTful Web
Services
Batch

Jakarta EE 9 Waves
Wave 5
Enterprise Beans
Standard Tag Library
Connectors
Wave 6
Security
Wave 7
Jakarta EE 9
Full Platform
Server Faces
Jakarta EE 9
Web Profile

スケジュール
2月 3月 4月 5月 6月
1 8 15 22 29 7 14 21 28 4 11 18 25 2 9 16 23 30 6 13 20 27
2月1日各コンポーネントのプランレビュー
2月14日すべてのAPI jarの提供
3月13日プラットフォームTCK完成
5月4日
Full/Webプロファイル RC
Full/Webプロファイルリリースレビュー開始 6月12日

https://github.com/orgs/eclipse-ee4j/projects/17
現在の状況

Jakarta EE 9 その他の修正(リリースプランにない話)
@Repeatable
Java EE 8で付け忘れていたものは追加
可能
@Deprecated 非推奨?削除予定のAPIに付けるのは可

Jakarta EE 9 その他の修正(リリースプランにない話)
プロパティ名
javaxで始まるプロパティは、jakartaに変更する
ランタイムによっては、javaxとjakartaの両方を
サポートするかも。
ジェネリクス
修正可能にするかどうか、検討中
Jakarta Authenticationで修正要望あり
例: Map → Map<String, String>

各仕様プロジェクトは任意のリリース間隔で出せるべき。
長い間隔は必ずしもネガティブではない。安定性も大事。
コミュニティに聞いてみる。
リリース間隔を改善する文書を作成し、フィードバックを
もらう。
リリース間隔(ステコミでの議論)

スキーマのURLは変更するのか?しなければならないのか？
Jakarta EE 8/Java EE 8以前は、JCPのURLを使用。
スキーマ (リリースプランにない話)
? http://xmlns.jcp.org/xml/ns/javaee/application_8.xsd
? http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd
Java EE 8の例
? http://xmlns.jcp.org/xml/ns/javaee/application_7.xsd
? http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd
Java EE 7の例

スキーマのURLは変更するのか?しなければならないのか？
Jakarta EE 8以前のスキーマはオプショナルとする
スキーマ (プラットフォームプロジェクトでの議論)
?
採用
案1
Jakarta EE 8以前のスキーマは必須とする案2
Jakarta EE 8のスキーマは必須、
それ以前はオプショナルとする
案3

互換性は重要。Java EEからの継続方針。
2020/Q1に互換性ポリシーのドラフト作成
コミュニティでの議論
ステコミでのアクション
Jakarta EE 10以降では非互換なし。
(OpenJDKのような)インキュベーションモデルは？
互換性 - backward compatibility

Jakarta EE 10に備えて、ツールの整備
ツール
テストツール
モニタリングツール
移植ツール
IDE
Jakarta EE 9 ツーリングリリース

Eclipse WTP(*)
? Eclipse Che
? Eclipse Desktop
? NetBeans
? IntelliJ
? VS Code
2020/Q4 にJakarta EE 9とJakarta EE 10
をサポート目標
(*) Web Tooling Platform
主要IDEに期待
サポート予定
IDE

https://github.com/bjhargrave/transformer
パッケージトランスフォーマー
Apache Tomcat migration tool for Jakarta EE
https://github.com/apache/tomcat-jakartaee-migration
移植ツール

クラス内で使用されているパッケージ名の変更
APIとコマンドラインI/F
javax → jakarta
任意のルールも設定可能
クラスローダーからの使用可能(実行時に変換)
コマンドラインI/F
jar/war/classが対象
パッケージトランスフォーマー

時間があれば
この時点で残り２０分ならＯＫ
デモ

2020/Q3
2020/Q2
2020/Q4
? 内容とターゲット日の作成
? リリースモデルの作成(間隔とかタイムベースとか)
リリースプラン詳細の作成
リリース
Jakarta EE 10

Jakarta EE と MicroProfile

本日お話しすることには
未確定事項が含まれています。

> 信頼性、可用性、スケーラビリティ、
性能を持つエンタープライズ向け
アプリケーションの走行を目的
> 複数のMicroProfileランタイム間での
アプリケーションのポータビリティを提供
> 既存のJava EE技術者のスキルを
有効活用
ECLIPSE
MICROPROFILE
Specifications for enterprise Java
microservices

MicroProfile 実装とプロジェクト
58
● Red Hat - Quarkus
● Red Hat - Thorntail
● Red Hat - Red Hat Application Runtimes
● IBM - WebSphere Liberty
● IBM - Open Liberty
● Payara - Payara Micro
● Payara - Payara Server
● Tomitribe - TomEE
● Oracle - Helidon
● Fujitsu - Launcher
● SmallRye
● Hammock
● KumuluzEE

MicroProfile 3.2 リリース
59
: 更新：新規
JAX-RS 2.1JSON-P 1.1CDI 2.0
Config 1.3
Fault
Tolerance 2.0
JWT
Propagation 1.1
Health
Check 2.1
Metrics 2.2
Open Tracing
1.3
Open API 1.1
Rest Client 1.3
JSON-B 1.0
: MicroProfile 3.1から変更なし
Eclipse MicroProfile 仕様

オープンで、最良のクラウドネイティブ技術とともに、
JavaとJakarta EEを使う
クラウドネイティブJavaに対する新しいビジョン

Eclipse Foundation
ベンダーコントリビューター
Jakarta EE
ワーキンググループ
MicroProfile
コミュニティ
ステークホルダー
IPフロー
技術的融合ガバナンス
(予算?仕様)

コントリビューター
参照
特許特許
実装品
実装
このダウンストリームラインセンスは、
ASLやEPLではカバーされていない
IPフロー
仕様
特許
実装者

Jakarta EEでは以下の４つでカバー
Eclipse Foundation Specification License
Participation Agreement
Eclipse Foundation TCK License
IP Policy
現在のMicroProfileのプロセスでは問題あり
仕様ライセンス

MicroProifleは標準化団体か？
標準化団体とは
NO
ISO、OASIS、W3C、、、
MicroProfile設立時には、「仕様策定はJCP等で行う」
と言っていた。
今のMicroProfile仕様は？
仕様の標準化

予算?メンバーシップを統一
それぞれの委員会を設置
Jakarta EEワーキンググループ
ステアリング委員会
仕様委員会
マーケティング委員会
CN4Jワーキンググループ
ステアリング委員会
Jakarta EE 仕様委員会
Jakarta EE マーケティング委員会
MicroProfile 仕様委員会
MicroProfile マーケティング委員会
ワーキンググループの統合(案)

パッケージ名
互換性
MicroProfileは、org.eclipse.microprofile
Jakarta EEは、jakarta (注)
MicroProfileは、非互換を許容、メジャーアップで対応
Jakarta EEは、非互換なしのポリシー
(注)jakartaでなければならないことはない
主な技術的課題

Innovations Graduate to Jakarta
APIをjakarta名前空間に変更
https://github.com/eclipse/microprofile-sandbox/blob/71db5e6cc710ef8d4968195527af13b4f1207077/proposals/techical-
alignment/proposal-specifications-graduation-to-jakarta.adoc
ベンダーはオプションとして、org.eclipse.microprofile
パッケージを互換として提供してもよい
一旦Jakartaに提供されたものは、Githubリポジトリを凍結
技術アライメント(提案)

Pullモデル Pushモデル
68
MicroProfileは、Pullモデルを提案中
ダウンストリームを気にせず
一方的に作る
Pullモデルと Pushモデル (最近の議論)
成熟したものをJakarta
EEへ提供

ダウンストリームを気にせず一方的に作る
作成 pull
?パッケージ名
?互換性
?ライフサイクル
Pullモデル
MicroProfile 利用者
仕様

成熟したものをJakarta EEへ提供
作成
push
?パッケージ名
?互換性
?ライフサイクル
Pushモデル
MicroProfile 利用者
incubation
仕様
仕様
成熟
graduation

最後に

Jakarta EE へ参加しましょう
https://wiki.eclipse.org/How_To_Contribute
仕様、ソースコード、TCK、Webサイトなど
様々な形で参加可能

Thank
you!

狠狠撸

JakartaOne Livestream Japan 2020

Convert to study materialsBETA

More Related Content

JakartaOne Livestream Japan 2020