Jakarta EE 9 とこれから

2021年1月26日
数村憲治
Jakarta EE 9とこれから
Copyright 2021 FUJITSU LIMITED
0

アジェンダ
1. Jakarta EE とは
2. Jakarta EE 9
3. Jakarta EE 9.1
4. Jakarta EE 10 and Beyond
5. CN4Jアライアンス
6. 最後に
1

Who am I ?
}
{
“名前”: “数村憲治”,
“勤務”: “富士通”,
“Jakarta EE”: “Specification Committee メンバー”,
“JCP”: “EC メンバー”,
“Eclipse Foundation”: “ボードディレクター”,
“Twitter”: “@kkzr”
2

アジェンダ
2. Jakarta EE 9
3. Jakarta EE 9.1
6. 最後に
3

Jakarta EE
■ オープンな仕様
■Jakarta EE Specification Process
■コードファースト
■ オープンソースTCK
■Eclipse TCK License
■オープンな認証プロセス
■ 互換実装
■Jakarta EE Platform (Full Platform/ Web Profile)
4

Jakarta EE コミュニティ
18 団体メンバー
123 新規コントリビューター
～65M コードステップ数
31 オープンソースプロジェクト 60 GitHubリポジトリ
5

ロードマップ
2019/9
Jakarta EE 8 Jakarta EE 9 Jakarta EE 9.1 Jakarta EE 10
2020/11 2021/? 202x
次のステップ
■ CDI中心
■ Java SE の最新技術を利用
■ ポータビリティとベンダー中立
6

Jakarta EE 8 互換実装
7

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

Jakarta EEの組織
Jakarta EEワーキンググループ
方向性の決定
Platformプロジェクト
[プランの作成]
各仕様プロジェクト
各仕様プロジェクト
[仕様の作成]
EE4Jプロジェクト
承
認
委
任
ステコミ(Steering Committee) 仕様委員会
実装プロジェクト(GlassFishなど)
[実装の作成]
9

アジェンダ
2. Jakarta EE 9
3. Jakarta EE 9.1
6. 最後に
10

Jakarta EE 9 コンセプト
■ 容易な新規参入
■新たなベンダーが互換実装を作りやすくする
■コードファースト
■ イノベーションの基礎
■Cloud Native Javaへのキーステップ
■ 簡単な移行
■新しい名前空間へ移行するためのプラットフォーム
11

スコープ
■名前空間の変更
■古い仕様の削除
■Java SE 8の仕様を追加
■ドキュメントのアップデート
■javax.* -> jakarta.*
■Jakarta EE 8 のドキュメントは、Java EE 8を
参照させる形式
■Jakartarize
12

名前空間の変更
■APIパッケージ名のトップレベルをjavaxからjakartaに変更
■ビッグバン v.s. インクリメンタル
■javaxは、APIを変更しない場合に限って使用可能
■この制約により、Jakarta EE 8では機能追加がなかった
■これから、Jakarta EEに機能追加していくために、javax
を使わないよにする
■必須仕様も、オプション仕様も、すべてのAPIをJakarta EE 9
で変更するビッグバン方式
13

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

スキーマ
 Java EE 8
 Java EE 7
 http://xmlns.jcp.org/xml/ns/javaee/application_8.xsd
 http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd
Jakarta EE 8/Java EE 8以前は、JCPのURLを使用
 http://xmlns.jcp.org/xml/ns/javaee/application_7.xsd
 http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd
 https://jakarta.ee/xml/ns/jakartaee/application_9.xsd
 https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd
Jakarta EE 9のスキーマは、jakarta.eeのURLを使用
https://jakarta.ee/xml/ns/jakartaee/#9
■Java EE 8のスキーマ―も利用可能(Java EE 7以前はベンダー依存)
■スキーマ一覧
 Java EE 9
15

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

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

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

Pruning
■Java EE仕様で使われていたPruning(=Optional)
とは意味が変わっている。
■ 古いAPIを仕様から削除することで、新規参入障壁を軽減
■ 仕様から削除された仕様を製品として提供するかは、
ベンダー次第
仕様からの削除提供されない
19

Jakarta EE 9 で Optional になった仕様
■Jakarta Enterprise Beans 2.x API group
■Jakarta Enterprise Web Services, JSR 109
20

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

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

対応ツール(調整中・対応中)
IDE
• Eclipse Che
• Eclipse Desktop
• NetBeans
• IntelliJ
• VS Code
移植ツール
• Eclipse Transformer
• Apache migration tool
モニタリング
• New Relic
• AppDynamics
• DataDog
• Elastic
テスト
• JBoss Arquillian
23

移植ツール
■ Eclipse Transformer
■ Apache Tomcat migration tool for Jakarta EE
■https://projects.eclipse.org/projects/technology.transformer
■https://github.com/eclipse/transformer
■https://github.com/apache/tomcat-jakartaee-migration
24

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

アジェンダ
2. Jakarta EE 9
3. Jakarta EE 9.1
6. 最後に
26

仕様委員会 2021年計画
■新リリース [第一優先]
■スピードアップ[第二優先]
■Jakarta EE 9.1 - JDK11対応
■各仕様のアップデート
■9.x プラットフォームリリース (インクリメンタルに機能追加)
■優先度・プランについて、コミュニティからのフィードバック
■仕様プロジェクトと実装プロジェクトの分離
■TCKのモダナイズ
■Jakarta EE 10 メジャーリリース
■GlassFish 依存解消
27

Jakarta EE 9.1
2021年1月31日までに、Platformプロジェクトで、リリースプラン決定
できるだけ単純に
2021年1月末
プランレビューリリース
2021年??月
28

ここから後は、ほとんど未確定情報
29

スコープ – Jakarta EE 9.1
■ 仕様は、Jakarta EE 9と同じ
■ Java SE 11 サポートの追加のみ
■ Platform Specification と
Web Profile Specification のみ
APIのアップデートはなし
30

Java SE 11対応
■ もともと、Jakarta EE 9で、Java SE 11対応予定
■ 2020年6月に、「Java SE 8を必須」、に変更
Java SE 11必須、Java SE 8はオプショナル
TCKの対応が困難
Jakarta EE 9 リリース後、
Jakarta EE 9.1 で速やかにJava SE 11対応
31

Java SE 11対応
■ API ソースレベル
■ TCK ソースレベル
■target/source レベルは、引き続き、Java SE 8レベル
■API(jarファイル)は、Java SE 8と11の両方で使われる
■TCKはJava SE 8レベルでコンパイル
■一つのTCKバイナリで、Java SE 8と11の両方で、
互換テストに使用できる
32

互換実装
■ Eclipse GlassFishが候補
■ CI (互換実装)が、どのようにJava SE 11ランタイム
をサポートするかは、ベンダーしだい。
JPMSなど
Jakarta EE 9.1互換のEclipse GlassFishがいつリリース
されるかは、GlassFishコミュニティ次第
33

各仕様のマイナーアップデート
■ APIのアップデートは、Jakarta EE 9.1には含めない
■ APIに影響を与えないドキュメントの修正は可
■ 2021年1月末までに、個別のリリースプランが必要
■バグ修正は含める
34

Jakarta EE 9.1 APIs
■ PlatformとWebProfileのAPI jarは、再作成
■ 中身は、Jakarta EE 9.0のjarファイルと同じ
■ maven artifact を見やすく、探しやすくするため
35

アジェンダ
2. Jakarta EE 9
3. Jakarta EE 9.1
6. 最後に
36

バージョニング
■基本的にSemantic Versioningに従う
■機能追加は、マイナーバージョンアップ
■非互換がある場合に、メジャーバージョンアップ
Jakarta EE
9.1
Jakarta EE
9.2
Jakarta EE
10.0
Jakarta EE
9.0
Java SE 11対応機能追加非互換を伴う機能追加
・・・
37

リリース間隔
■Feature Release v.s. Time Box
■Time Box
■LTS v.s. STS
１年に１回？
半年に１回？
２年に１回？
３年以上？
仕様としての長期サポートの意味は
38

Java SE リリースとの同期
■Java SE 17が2021年リリース予定
■今後、Java SEのアップデートと同期するのか？
Jakarta EE はいつ対応するのか？
39

CDI Lite
 Jakarta DI
 Jakarta CDI Lite
 Jakarta CDI Core
 Jakarta CDI EE
AOT、Build Time Injectionなどへの対応のためレベル分け
40

設定の外出し
■クラウド・コンテナ利用時のポータビリティ実現
■MicroProfile Configuration
Build Once, Run Anywhere
MicroProfileの仕様を、どのように
Jakarta EEに取込むか？
41

既存仕様のアップデート
■Jakarta Security
■Jakarta Concurrency
■Jakarta Messaging
JWT, OAuth2などのサポート
■@MaxConcurrencyなどの追加
■Java SEのcompletable futureのサポート
■Message Driven Beanと同等のCDIサポート
■Kafka/MQTT/AMQP連携
■Java SEスタンドアローンAPI
42

既存仕様のアップデート
■Jakarta Persistence
■Jakarta Rest
■NoSQL/JCacheのサポート
■マルチテナンシーのサポート
■Java SEの Recordへの対応
■@Contextの替わりに@Injectのサポート
■Java SEスタンドアローンAPI
■multipart/form-dataのネイティブサポート
43

Jakarta EE Platform以外のJakarta 仕様
■Jakarta MVC 2.0
■Jakarta NoSQL
https://jakarta.ee/specifications/mvc/
https://jakarta.ee/specifications/nosql/
44

MVC
プロファイル(例)
Web Profile
+
Platform
外部
既存
オプション
新規
Enterprise Beans
Messaging
Activation
Mail
Connectors
Concurrency
Batch
Authorization
XML Binding
XML Web Services
Enterprise Web Services
SOAP with Attachments
Web Services Metadata
Enterprise Beans 3.x
Enterprise Beans 2.x
Cloud Profile
+
Web Profile
Servlet
Server Pages
Expression Language
Debugging Support
Standard Tag Libraries
Server Faces
WebSocket
Enterprise Beans Lite
Persistence
Transactions
Managed Beans
Interceptors
CDI
Authentication
RESTful Web Services
JSON Processing
JSON Binding
Annotations
Bean Validation
Dependency Injection
Security
Cloud Profile
CDI Lite
Config
45

アジェンダ
2. Jakarta EE 9
3. Jakarta EE 9.1
6. 最後に
46

実装プロジェクトと仕様プロジェクト
https://projects.eclipse.org/projects/ee4j
実装プロジェクト
と仕様プロジェクトで
運用ルールが違う
EE4Jプロジェクト一覧(抜粋)
先頭に、「Eclipse」が付いているのが
実装プロジェクト
先頭に、「Jakarta」が付いているのが
仕様プロジェクト
47

仕様のIPフロー
仕様実装品
コントリビューター
実装者
このダウンストリームラインセンスは、
ASLやEPLではカバーされていない
特
許
実装
特
許
特
許
仕様を実装する目的
でライセンスされる。
改変はできない。
仕様リリース前に
特許の使用を
認める。
48

Eclipse Foundation内での運用
■以下の４つで仕様ライセンスをカバー
■Eclipse Foundation Specification Process(EFSP)
仕様策定する場合は、このプロセスに従う必要あり
■Eclipse Foundation Specification License (EFSL)
■Eclipse Foundation TCK License
■Participation Agreement
■IP Policy
49

Eclipse MicroProfile
■MicroProfileの仕様を策定するプロジェクト
■これまで(*)のMicroProfileのプロセスでは問題あり
■仕様が、EFSLで提供されていない
■EFSPにしたがったプロセスでない
MicroProfile 4.0がリリースできない
Working Group/仕様委員会の設立が必要
50
(*) 2020年10月

MicroProfile ワーキンググループ
■Jakarta EEとは独立したWG
■仕様を策定するのに必要
■2020年10月に設立
■参加メンバー(2021年1月現在)
IBM、Red Hat、Tomitribe、Oracle、Payaraなど
■Steering Committeeが仕様の承認
(独立した仕様委員会は設けない)
■2020年11月にMicroProfile 4.0をWGとして初めてリリース
■2021年1月にMicroProfile 4.1をEFSLでリリース
51

MicroProfile と Jakarta EE
2019年秋
CodeOne開催時に、
主要ベンダーでMPWG
の設立意向を確認
2020年初 2020年夏 2020年秋
MicroProfileがJakarta
EEに合流する方向
Umbrella WG 構想
独立したWGとして設立
Jakarta EE WGの予算
の一部が MPWGへ
Cloud Native for Java
構想
52

CN4J アライアンス
■MicroProfile と Jakarta EE のシナジーが目的
■ゴール
■ノン・ゴール
■一貫したマーケティング・プロモーション
MicroProfileとJakarta EEは競合ではない
■技術討議をする場を設ける
Jakarta EEはどのようにMicorProfileのAPIを取り入れるか
■現在の、MicroProfile と Jakarta EE WGの構造を変える
■新しいWGを作る
53

■Push v.s. Pull (2020年春)
■CN4Jアライアンス (2021年初)
MP APIをJakarta EEにどう取り込むか
forkは好ましくないという議論が白熱
forkする・しないで、議論が再燃
MicroProfile Jakarta EE
互換性非互換許容互換性重視
リリースサイクル数回/年 1回/年(？)
パッケージ名 org.eclipse.microprofile jakarta.ee
■[MPコミュニティ] Pullモデルを選択
■[Jakartaサイド] APIを取込むので、MP APIをforkする。
54

Push/Pullモデル
仕様
作成
push
MicroProfile
・パッケージ名
・互換性
・ライフサイクル
仕様
incubation
graduation
成熟
作成 pull
MicroProfile
Pushモデル：成熟したものをJakarta EEへ提供
Pullモデル：ダウンストリームを気にせず一方的に作る
仕様
利用者
・パッケージ名
・互換性
・ライフサイクル
利用者
55

仕様共有案
案1：MicroProfileの仕様を名前空間を変えずに
Jakarta EEに移動
MicroProfileのブランドが混乱
案2：MicroProfileの仕様を名前空間を変えて
Jakarta EEに移動
MicroProfileは互換性の担保が必要
案3 :MicroProfileの仕様をJakarta EEが参照
循環依存が発生
案4 :Jakarta EEで独自に作る
依存関係は解消できるが、冗長で、
似て非なるものができる。
56

アジェンダ
2. Jakarta EE 9
3. Jakarta EE 9.1
6. 最後に
57

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

Question?
59

Jakarta EE 9 とこれから

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Jakarta EE 9 とこれから

Similar to Jakarta EE 9 とこれから (20)

More from Kenji Kazumura

More from Kenji Kazumura (9)