2023-02-28に開催されたオンラインセミナーであるJava Developer Summit 2023 Track-2での資料です。MicroProfileを選択する理由、Jakarta EE, Java EEと比較してどうなのか、Spring Frameworkをどうして選択しなかったのか、そして採用した場合にどこで困ったのか、どうやって解決したのか、等々を50分に圧縮して説明しました。

1. MicroProfileの
正しい使い方

2. 岩崎浩文

3. Agenda

4. 1.なぜ
MicroProfile
仕様なのか

5. プロプライエタリー vs. オープンソース
独自仕様 vs. デファクトスタンダード
破壊的Ver.UP vs. 後方互換性
……どちらを選びますか?

6. オープンソースで
世界的なデファクトスタンダードで
後方互換性を持っている基盤
Jakarta EE Microprofile
(今回はこっちの話です)

7. 基盤選択のための技術者視点での観点
長期利用の観点
• 例えば10年後にも小手直しを繰り返して
メンテナンス可能か?
開発者確保の観点
• 例えば10年後も開発者確保できるか?
• 「2025年の崖」の問題は再発しないのか?
外的環境の観点
• 例えば10年後にもオンプレミスで動作させるつもりか?
• 逆にずっとクラウドを使い続けるつもりか?
トレンドの観点
• イケてるのかダサいのか?
• 自己満足のために評価の定まってない
新規のものを導入してしまってないか?
投資の観点
• その活動は巨額投資に見合ってるか?
• 見返りが見込めないものに技術的理由を
後付けして強行しようとしていないか?
(おまけ)
……等など。正解はないです

8. 鉄板のエンプラ基盤選択トレンドの変化
2000 2010
J2EE ~ Java EE
Mainframe
1980 2020
(今回はここの話です)
System/360
CICS
Linux
Java
J2EE
Cloud
Internet
.NET FW
MQ
RDBMS
Machine
Learning
Python

9. Jakarta EE と MicroProfile
Jakarta EE MicroProfile

10. 1. ファイルサイズの極端な違い
Jakarta EE MicroProfile
Jakarta EE準拠
App Server
Java VM
作ったWAR
数十MB
~800MB
300MB
50MB + 10MB
Java VM 300MB
作ったJAR MicroProfile
50MB
何故これが効くのか?
▼
クラウドの課金モデルに有利
(小さいのは正義)

11. コンテナー
コンテナー
2.「何でも入り」が重複する時代
Jakarta EE MicroProfile
Jakarta EE準拠
App Server
Java VM
作ったWAR
Java VM
作ったJAR MicroProfile
コンテナー
側の実装
• パッケージング
• バージョニング
• ルーティング
• …
コンテナー
側の実装
• パッケージング
• バージョニング
• ルーティング
• …
重複
App Server側の実装
• パッケージング
• バージョニング
• ルーティング
• …
重複無し
何故これが効くのか?
▼
クラウドエンジニアが活用
可
(高額なJEE知見者不要)

12. 3.コールドブート速度(配備込み)
Jakarta EE
MicroProfile
数秒~30分
(WARがデカくなればどんどん遅くなる)
0.5秒~5秒
何故これが効くのか?
▼
秒単位課金の
レスポンシブデザイン可
(クラウドネイティブ)

13. 3.コールドブート速度(配備込み)
Jakarta EE
MicroProfile
0.5秒~5秒 リクエストが来てから起動可
能
▼
秒単位の課金モデル対応
(Google Cloud Runなど)
いわゆるレスポンシブデザイ
ン
いわゆるレス
ポンシブデザ
インは
遅すぎて無理
数秒~30分
(WARがデカくなればどんどん遅くなる)
GraalVMにするだけ
で
更に1-2秒短縮可能。
ネイティブコンパイ
ルで
0.1秒起動も可
何故これが効くのか?
▼
秒単位課金の
レスポンシブデザイン可
(クラウドネイティブ)

14. Jakarta EE 10 と MicroProfile 6の
新たな関係
Jakarta EE 10
MicroProfile 6
Jakarta EE 10
Core Profile
MicroProfileはJakarta EE
の一部になった
→利用側には
特に意味が無い変更
Annotations 2.1
CDI 4.0 Lite
DI 2.0
Intercepters 2.1 JSON-P 2.1
JSON-B 3.0
JAX-RS 3.1
Config 3.0
Fault Tolerance 4.0
Health 4.0 JWT Auth 2.1
Metrics 5.0
OpenAPI 3.1
Telemetry 1.0
Rest Client 3.0
Mail
JTA
JPA
CDI 4.0
JMS
JSF
JSP
etc.
クラウド環境
では
あまり使われ
ないものが残
った

15. MicroProfile 6でクラウド対応(ネイティ
ブ)
アプリケーション構築時に重要な仕様
MicroProfile 6
Jakarta EE 10
Core Profile
Annotations 2.1
CDI 4.0 Lite
DI 2.0
Intercepters 2.1 JSON-P 2.1
JSON-B 3.0
JAX-RS 3.1
Config 3.0
Fault Tolerance 4.0
Health 4.0 JWT Auth 2.1
Metrics 5.0
OpenAPI 3.1
Telemetry 1.0
Rest Client 3.0
ConfigやRestClientは
恐らく使わないことが少ない
と思われる(ほぼ必須)

16. MicroProfile 6 Standalone APIs
MicroProfile 6
Jakarta EE 10
Core Profile
Annotations 2.1
CDI 4.0 Lite
DI 2.0
Intercepters 2.1 JSON-P 2.1
JSON-B 3.0
JAX-RS 3.1
Config 3.0
Fault Tolerance 4.0
Health 4.0 JWT Auth 2.1
Metrics 5.0
OpenAPI 3.1
Telemetry 1.0
Rest Client 3.0
MicroProfile 6
Standalone
Open Tracing 3.0
LRA 2.0
Reactive
Messaging 3.0
GraphQL 2.0
Reactive Streams
Operators 3.0
Context Propagation 1.3
Standalone =
Framework実装によって
サポートしたりしなかったり
マチマチ

17. 1のまとめ
1. 従来のJakarta EE仕様は既にトレンドから外れている
2. Jakarta EEから古いものを削ったものがMicroProfile
3. 新規で作る場合はMicroProfileを選択する方が賢明

18. 2.3年間
MicroProfileを
使い続けてみ
て

19. Java EEを捨てMicroProfileにした
• 理由1
• Java/Jakarta EE仕様がいつまでたっても
バージョンアップしない! (EE 8-9-10で足
踏み)
• 理由2
• クラウド対応をあまり考慮してくれない!
• 理由3
• アプリケーションサーバーをもうこれ以
上使いたくない!
• 理由1の背景
• 他のプラットフォームから引き離される
一方
• コミュニティー移行に注力しすぎ
• 理由2の背景
• オンプレミス大前提時代に作った仕様な
のでしょうがない
• 理由3の背景
• クラウドのコンテナー機能とアプリケー
ションサーバー機能が被りまくりで無駄
……

20. 何故Spring Frameworkではなく
MicroProfileだったのか (よく聞かれるの
で)
• デファクトスタンダード仕様だから
• 後方互換性を一応考慮に入れてくれてるから
• 未来がありそうな気がしたから

21. MicroProfile実装にはHelidonを選択した
• 小さくてシンプルだから
• トランザクション制御の信頼性があったから
• 挙動が素直だから

22. Helidonのいいところ、とそうでないと
ころ
Helidonのいいところ Helidonの微妙なところ

23. Helidonのいいところ、とそうでないと
ころ
Helidonのいいところ Helidonの微妙なところ
Helidon採用のお勧め方面
▼
挙動が見えてないと不安
シンプルイズベスト
あとは自分で何とかしたい系

24. Helidonで始めるために必要な情報
必要なもの (特別なものはなし) 事前に理解しとくとわかりやすい点

25. 理解しとくと便利 その1
プロジェクト作成=Mavenコマンド
コマンド ポイント

26. 理解しとくと便利 その2
実装ベースはただのCDI=Jakarta EEと共
通
いまさら特
に語ること
もないで
しょう……

27. 理解しとくと便利 その3
Dockerイメージ化・起動・クラウドへ
コマンド ポイント
このイメージ
をクラウドに
持っていって
も同様に動作
する

28. MicroProfile採用時の設計時ポイント1
• Jakarta EEにあったServlet、JSP、JSF等がない
• どうすべきか?
画面系ライブラリーな
し

29. MicroProfile採用時の設計時ポイント2
• Google Cloud Runのようなフルマネージドコンテナー環
境が今後主流になってくると予測
• そこでの利用を前提とした設計
コンテナー利用を前提
にした考慮点を入れる

30. MicroProfile採用時の設計時ポイント3
• 魅力が沢山 (主に￥￥￥の観点)
• 移植に当たってのヒント (割と悩ましい)
Jakarta EEから
MicroProfileへの移植
※完全に移植可能ではないので
注意すべし

31. 利用の実際: Helidon 2→3のバージョンアッ
プ
はどうだったのか?
• 割と困らず移行できた
• 引っかかった点

32. 結局MicroProfile/Helidonを使い続けて
どうだった?
• 全く何も困ってない
• 画面系をJavaでやるのはもう諦めた

33. まとめ

34. ありがとうござい
ました