2026/09/10 Spring_Bootから_Jakarta_EE_MicroProfileへの移行

【会場開催】Jakarta EE&MicroProfileセミナー「Spring BootからJakarta EE/MicroProfileへの移行」 9/10(木)開催 登壇資料

https://jakartaee.doorkeeper.jp/events/198856

Mythosが発表された後、以前に比べて多くの脆弱性が見つかるようになりました。脆弱性が見つかる数が増えただけではなく、脆弱性が見つかった後に早急にパッチを当てる必要があります。よりよいサポートを求めてSpring BootからJakarta EEやMicroProfile準拠サーバーへの移行を検討されるユーザーも増えています。このセッションでは、Spring BootとJakarta EE、MicroProfileの比較を行い、どういう点に気を付けて移行すればよいかについて説明します。

Transcript

1. Spring Bootから Jakarta EE/MicroProfileへの移行 9/10 日本 Jakarta EE & MicroProfile ユーザーグループ勉強会 Satoshi Seto 1 #JakartaEE
2. 免責事項 • • • • • 2 このセッションの情報はコミュニティの情報をまとめたものであり、内容に ついて誰かが責任を持つという事はありません。 内容については必要に応じてご自身でご確認の上、ご使用ください。 GraalVM(ネイティブ化)については取り扱いません。 MicroProfile(MP)については可能な限り汎用的な情報にしようとしまし たが、Quarkus固有の情報が紛れ込んでいます。 間違っている場所を見つけたらフィードバックをお願いします。
3. 求める前提知識 • • 3 Spring Bootを使用している ServletなどJakarta EEの用語をなんとなく理解している
4. 自己紹介 • • • • • 4 瀬戸智(@megascus) JJUG・Jakarta EEユーザーグループ Red Hatのソリューションアーキテクト 一時期Servlet APIとかJakarta Persistence APIの 翻訳とかしてました 最近はちいかわにハマってます。
5. アジェンダ 5 • なぜ今Spring BootからJakarta EE/MPなのか • Spring BootとJakarta EE/MPのアーキテクチャ比較 • 実際に移行で気を付けるべきところ
6. アジェンダ 6 • なぜ今Spring BootからJakarta EE/MPなのか • Spring BootとJakarta EE/MPのアーキテクチャ比較 • 実際に移行で気を付けるべきところ
7. なぜ今Spring Bootから Jakarta EE/MPなのか 7
8. なぜ今Spring BootからJakarta EE/MPなのか • • • 8 フレームワークロックインの解消 ◦ 特定ベンダー・フレームワーク独自APIへの密結合を解き、標準規 格（Jakarta EE/MP）準拠によるポータビリティの獲得 セキュリティ・ガバナンス対応 ◦ Mythos等の厳しいセキュリティパッチ適用要求に耐えうる、長期間 運用を見据えた安定した運用基盤 クラウドネイティブ化 ◦ Spring Bootよりも軽量で高速なランタイムの重要性
9. フレームワークロックイン Spring自体はOSSだが・・・・ • • • 9 Springの商標はBroadcomが持っている Java EE->Jakarta EEの問題はOracleがJavaの商標を重要視したため 発生 ◦ 結果としてパッケージ名の変更 他社がforkした場合に使用差し止めなどの可能性がある ◦ springパッケージを使えないことによる互換性破壊等
10. セキュリティ・ガバナンス対応 • • • 10 無償のコミュニティ版Spring Bootサポートは各マイナーリリースで1年間 のみサポートされる 互換性ポリシー自体は各ライブラリに委ねられているため、マイナー バージョンアップでAPIレベルからの互換性が崩れ、アプリの書き換えが 必要に Jakarta EEはJakarta EE仕様の同じバージョン間は互換性が担保され るので、Springに比べるとアップデートが容易い
11. クラウドネイティブ化 • • • 11 Springは期待したほど起動が早いわけではない Spring BootとJakarta EEサーバー(Glassfish、Wildfly、Liberty)を比べ るとだいたい起動時間が同じぐらい Quarkusは明らかに起動が早い
12. QuarkusとSpring Bootの起動速度・スループットの差 JVM状態でQuarkusはSpring Bootよりも • 2倍ほど起動が早い • 2倍のスループットを処理できる ※スループットはSpring BootでTomcat(Servlet)を使用する設定になっているた め比較としてはよくありません。WebFluxを使用する事で早くなります。 ※Jakarta EEサーバーのスループットはServletを使用するSpring Bootとほぼ 同等もしくは早いです。(ものによります) 12 https://github.com/quarkusio/spring-quarkus-perf-comparison https://quarkus.io/
13. Spring Bootの起動が遅い理由: AutoConfiguration • 実行時にアノテーションを読み、動的にクラスをロー ドする仕組み。 • ユーザー側でBeanが定義されていない場合に、足り ないBeanを再帰的に探し出し、必要な設定を組み立 てる。 • Springの肥大化に伴いどんどん遅く • SB3から4で仕組みが改善されたが、それでも遅い。 ※先のQuarkusとの比較の表ではSB4を使用 13
14. Jakarta EEサーバーの動的モジュールロード • Glassfish/Liberty/Wildflyはモジュール化されてお り、必要なモジュールのみ動的に読み込まれる • 動的なBean定義に比べると軽量 • 必要なモジュール自体だけを組み立ててさらに軽量 化できる場合もあり(Liberty/Wildflyなど) ※図はLibertyの説明資料より 14 https://community.ibm.com/community/user/viewdocument/20250807-java-eejakarta-ee?CommunityKey=d6c93aa2-6e10-48da-96dc-3831da8ee185&tab=librarydocuments
15. Quarkusが早い理由：Quarkusのコンパイル時DI • 起動時にBeanを生成していたのを、すべてコンパイ ル時に行う • 起動時の処理が減るため、起動時間が短くなる ※Spring BootやJakarta EEサーバーでやりがちな起動 時に環境情報を読み込んで最適化することができなくな るので注意 ※CI/CDとの統合が前提とされた仕組み 15 https://quarkus.io/performance/
16. アジェンダ 16 • なぜ今Spring BootからJakarta EE/MPなのか • Spring BootとJakarta EE/MPのアーキテクチャ比較 • 実際に移行で気を付けるべきところ
17. Spring BootとJakarta EE/MPの アーキテクチャ比較 ～すべてが良くなるわけではなく～ 17
18. Spring Boot アーキテクチャ Servlet API Jakarta REST Spring Web • Jakarta Persistence • Spring Security Spring Data Spring Boot Jakarta XML Jakarta JSON Spring DI Spring Cloud Spring AOP Spring Projects Jakarta Validation Jakarta WebSocket Jakarta EE 仕様 (標準仕様 ) Jakarta Mail 18 • 中心に変更の早いSpring Projectのライブラリ がおかれ、外部に変化の少ないJakarta EEの 仕様に準拠したライブラリが配置されている コア部分のライブラリのAPIが変更されることが あり、アプリケーションへの影響が大きい 実行時にDIで依存関係が構築されるため、環 境に応じた柔軟性がある
19. Jakarta EE アーキテクチャ • • サードパー ティライブラ リ 19 • Jakarta EE サーバーでは安定した仕様が決め られており、コア部分の変更を少なくできる Kafkaなどの新しめの技術への対応は仕様化 されていないため、ある程度の非互換は許容 する必要があるが、影響を局所化可能に 実行時にDIで依存関係が構築されるため、環 境に応じた柔軟性がある
20. Jakarta EE の3階層のプロファイル  Full Platform  Web Profile  Core Profile レガシーシステム向け 移行時の推奨・標準 特殊用途 (原則非推奨 ) • • 古くからJava EE(J2EE)を 使用している場合に選択す る • Spring Bootから移行する 場合は、まずこれを選択 する EJBなど重量級の仕様が 含まれているため、重い サーバー構成になりがち • Web UIやDBアクセス、DI などの主要な必要機能 • Spring Bootと同程度の起 動速度と性能 • MicroProfile用に便宜的に 作成されたプロファイル • 通常開発では基本的に使 用しない ※APサーバーによっては仕様毎に組み合わせて、独自の「オリジナルプロファイル」を作成することも可能 20
21. (参考)APサーバーの依存するJakarta EEのバージョン • • • 21 Jakarta EEは仕様であり単体では動かない 実装するAPサーバーが常に最新仕様を実装しているとは限らない ◦ Jakarta EE 11仕様のGAは2025年6月 ◦ Spring Boot 4(Jakarta EE 11仕様準拠)のGAは2025年11月 Jakarta EEサーバーは安定性を重視するため、Spring Boot 4よりも準 拠する日付が遅め ◦ 新しい機能が使えるようになるまで時間がかかる ◦ Spring Bootと共通のライブラリも多いので、OSS版でバグが取れ たライブラリが入ってきやすいなど利点もある
22. MicroProfile アーキテクチャ • • • • • 22 https://docs.google.com/presentation/d/19cqC0okjXE-BzZAByUkFbYv5KfWTobT6ct5YpAXVe4I/edit?pli=1&slide=id.p8#slide=id.p8 Jakarta EEの一部(Core Profile)とJSON API、ReactiveプログラミングやKubernetes連 携(監視)用APIが定義 仕様間での互換性ポリシーがJakarta EEに比 べると低い(Springに近い) DB連携などは仕様化されていない MicroProfile仕様の範囲だけで実用的なアプリ ケーションを作ることは出来ない MicroProfile仕様間でのポータビリティは期待 できない
23. Quarkus アーキテクチャ Hibernate ORM (JPA) Qute MicroProfile LRA MP Config • MP Telemetry Quarkus • • CDI (Arc) MP Health LangChain4j • MP Rest Client MicroProfile Jakarta EE/その他 Apache Kafka Jakarta Servlet CDIを中心にMicroProfileがおかれ、外部に 変化の少ないJakarta EEの仕様に準拠した ライブラリが配置されている Jakarta EE仕様/MicroProfileに準拠してい ないライブラリもあり(UIライブラリなど) Jakarta EEに比べるとSpringに近い形 コンパイル時DIのため、VUPするたびにコン パイルしなおしが必要になる
24. (参考)MicroProfile 実装サーバーの分類 Jakarta EE型 Servletベース型 非Servletベース型 Jakarta EEサーバーのアドオ ンとしてMicroProfile機能を追 加 ServletにMicroProfile仕様を 搭載 Servletモデルを排し、Netty等 の高速IOベースで構築 代表的な実装 : 代表的な実装 : 代表的な実装 : • Launcher • Quarkus • WildFly • • Helidon • Open Liberty Quarkus(+ Servlet) • • • Payara Server Helidon (+Servlet) Open Liberty (極小構成 ビルド)
25. アジェンダ 25 • なぜ今Spring BootからJakarta EE/MPなのか • Spring BootとJakarta EE/MPのアーキテクチャ比較 • 実際に移行で気を付けるべきところ
26. 実際に移行で気を付けるべきと ころ 26
27. 実際に移行で気を付けるべきところ • • • • • • • • • 27 パッケージング・デプロイメント DI(Dependency Injection) UI(HTML、JSON API) データベースアクセス セキュリティ(Spring Securityからの移行) AI 設定ファイル バッチ(Spring Batchからの移行) そのほか
28. パッケージング・デプロイメ ント 28
29. Bootable-jar から アプリケーションサーバー Bootable-jarもしくはコンテナネイティブな自動インストール かつてのJava EEサーバーはプリインストールしていたが最近はその使用形 態は減ってきている。(減ってほしい) 脆弱性対応を考えるなら、OpenJDK(JVM)のバージョンアップも見据えてコ ンテナイメージとして管理するべき。 • • bootable-jarの作成(WildFly/Liberty/Quarkusなど) ◦ コンテナが使用できない場合 Mavenでの自動インストール(GlassFish/WildFly/Libertyなど) ◦ コンテナが使用できる場合 ※詳細はJJUGナイトセミナー「Jakarta EEの始め方と新機能」の田中さん、 長尾さん、瀬戸の資料を参照 29 ※Spring Boot(Bootable-jar)ができたのはDockerが普及する前です。 https://jjug.doorkeeper.jp/events/190122
30. pom.xmlの依存ライブラリとして何を書くべきか Jakarta EEのAPIだけを使用したい場合は、 akarta.platform.jakarta.jakartaee-web-api (Web 用のサブセット)もしくは jakarta.platform.jakarta.jakartaee-api(EJBを使い たい場合)を使用すればいいが、Jakarta EEで標準 化されてない機能が使用できない。 各APサーバーで推奨されているpom.xmlでの依存 関係の書き方がある(はずな)ので、各APサーバー のドキュメントを参照する事。 30
31. DI(Dependency Injection) 31
32. Jakarta EE/MPのDI機能: CDI • • • 32 Contexts and Dependency Injection ◦ コンテキストを持つのが特徴 ◦ リクエストごとにbeanのスコープが動的に組み立てられる デフォルトでSpring AOP相当の機能が組み込まれている ◦ @Aspectとか、@Aroundみたいなのをデフォルトで使用可能 ◦ 異なるスコープのbeanの組み合わせなども可能 同じCDIという名前でコンパイル時DIと実行時DIがある ◦ Jakarta EEサーバー:実行時DI(CDI Full) ◦ Quarkus: コンパイル時DI(CDI Lite) ◦ コンパイル時DI(CDI Lite)では一部機能が使えない ◦ 実行タイミングの挙動差異で困ることがある
33. 実行時DIのCDI • • • 33 アプリケーションの起動時にアプリケーション内のbean定義が読み込ま れ、依存性が動的に組み立てられる Jakarta EEサーバーは基本的にこの方式がとられる(はず) Spring DIとほぼ同じ使い勝手で使用する事が出来る
34. コンパイル時DIのCDI • • • • 34 コンパイル時にアプリケーション内のbean定義 が読み込まれ、依存性が動的に組み立てられ る Quarkusの方式 実行時に本番環境だけにあるjarを追加して環 境依存の処理をさせるみたいなことができない 実行時DIに比べると実行時の処理が少ないた め、起動の高速化が可能になる
35. Spring DIからCDIへのアノテーション変換 • • • 35 https://ja.quarkus.io/guides/spring-di/ Spring DIとCDIの機能は似ており、単純に変 換できるものも多い この表はQuarkusのページのものだが、 Jakarta EEサーバーでも使用可能 QuarkusではSpringのアノテーションを付けた ままCDIの仕組みで動かすことも可能
36. @Service、@Repository、@Controllerなどはない SpringにあるDDD由来のアノテーション(@Service、@Repository、 @Controllerなど)などはCDIにはありません。 必要に応じて自作する必要があります。 ※詳細はCDI Stereotypeで検索 36 https://docs.oracle.com/javaee/6/tutorial/doc/gkhqc.html
37. そのほかのCDIの注意点 Jakarta EE&MicroProfileセミナー「Jakarta CDI特 集(実践的活用方法とAI領域への拡張)」の吉崎さ んの資料を参照。 37 https://jakartaee.doorkeeper.jp/events/194702 https://speakerdeck.com/futokiyo/cdinowu-jie-sigatinashi-yang-tosonodui-chu-tips
38. UI(HTML、JSON API) 38
39. Spring MVCに代わる代替手段 Jakarta EEはUIまわりの技術が弱い Jakarta EEでサポートされるUI技術はJSP/Servlet、JSF、JAX-RS • • • 39 JSP/Servlet ◦ 単体でViewを作成するにはつらい JSF ◦ コンポーネントベース ◦ 作りやすいが大量のアクセスには向かない JAX-RS ◦ json/xmlの処理を行える ◦ API向け
40. コンポーネントベースのUI vs アクションベースのUI   コンポーネントベース (JSFなど) 40 • UIを部品の集合と考え、再利用可能なUI部 品（ボタン、フォームなど）に分割して管理 • パーツ化されているため、状態の管理が容 易 • UIの状態を持つ必要があるため、アクション ベースに比べるとリソース保持量が多い • リッチUI向け アクションベース (Spring MVCなど) • HTTPリクエストやイベントに対するアク ション毎にUIを定義する • ユーザーの操作に対して、どの画面を返 すかなので、処理がシンプルになる • アクションごとの関連を持たないため、処 理が容易だが、アクション間の関連が必 要になると複雑になりがち • シンプルなUI向け
41. 現実的にとりうるJakarta EE/MicroProfileのUI戦略 41     Jakarta Faces Jakarta MVC サードパーティ UI JAX-RS / SPA コンポーネントベー スの標準UIフレーム ワーク。リッチな画面 開発や状態管理が 容易。 Jakarta EE 12からサ ポートされる(はず の)標準MVCフレー ムワーク。シンプル かつ直感的な画面 遷移をサポート。 Jakarta EE/MicroProfile外 部の既存エコシステ ムや他フレームワー ク技術（Spring MVC など）の統合。 フロントエンド （Vue/React/Angul ar等）とJAX-RSによ るAPI通信を組み合 わせたモダンなアー キテクチャ。
42. Jakarta Faces(Jakarta Server Faces) • • • • 42 Jakarta EE標準で(実質)唯一選択できる選択肢 過度にHttpSessionに依存する作り ◦ 大量のサーバーリソースが必要になる ◦ 大量のアクセスには向かない ◦ セッションレプリケーションを使用する場合も覚悟が必要 コンポーネントベースで作りやすい ◦ 部品化、部品の再利用 (主に)社内システム向け
43. (参考)ステートレスなJakarta Faces: AliFaces • • • • 43 https://foojay.io/today/jakarta-faces-java-web-framework-stateless-edition-marketplace-alifaces/ 8月29日に書かれた記事 HttpSessionからJakarta Facesを分離 E-コマース向けに開発され、PoCを行っている とのこと 実現したら、軽量なJSFが使えるようになる(か もしれない)
44. Jakarta MVC • • • • • 44 https://www.docswell.com/s/MasatoshiTada/53J7RY-jakarta-mvc Jakarta EE 12 で入る(はずの)新仕様 JAX-RSベースの軽量なMVCフレームワーク Jakarta EE 10/11でも使用可能 Thymeleafと組み合わせることでSpring MVC に近い形で使える(はず) 詳細については前回の多田さんの資料を参照
45. (参考)エラー処理の改善PRが取り込まれました • • • • 45 https://github.com/eclipse-ee4j/krazo/pull/417 hasErrorsメソッド追加のPR #sets.isEmptyを使用する必要があった Krazoで取り込み済み、そのうちリリースされる はず 他も取り込んでくれてるので、Jakarta MVCが 気になる人は試してみて、微妙な点を修正して いきましょう
46. サードパーティのUI技術 (Spring MVCなど) • • • 46 昔から取られてきた戦略 SpringやStrutsなどはこの戦略の中で生まれた ◦ JSP/Servletだけで画面の開発なんてやってられない 脆弱性/アプリケーション更新時の非互換性を局所化するという意味で はアリ
47. JAX-RSを使用したSPA • • • 47 JSON API + フロントエンドのSPA MicroProfileでは第一の選択肢となる この後のセッションで詳しくしゃべってくれるはずっ・・・・
48. データベースアクセス 48
49. 現実的にとりうるJakarta EE/MicroProfileのDB戦略 49     JPA Jakarta Data 標準的かつ最も普 及している、Javaに おけるリレーショナ ルデータベース設計 の基本戦略。 リポジトリパターンを ベースに、より簡潔 で現代的なデータア クセスを実現する新 しい標準規約。 JDBC / サードパー ティライブラリ Hibernate Panache SQLを直接制御した り、既存のMyBatis、 jOOQなどの独自ラ イブラリを活用。 Quarkus環境限定。 アクティブレコードお よびリポジトリパター ンを極めてシンプル に実装可能。
50. Jakarta Persistence(JPA) • • • 50 すでにSpring Data JPA を使っている場合は、最有力候補だが・・・・ Spring Data JPA にあるグルーコードの自動生成機能(JpaRepository) はない AIを使って省力化する事が前提
51. Jakarta Data • • • Jakarta EE 11から入る新機能 Spring Data JPAのJakarta EE版 Jakarta EE 11時点では JPAとコンテキスト (L1, L2キャッシュ )が共有さ れないことに注意 ◦ JPAとJakarta Dataのどちらかにデータ更新処理を寄せないとデー タ更新の不整合が発生する可能性がある ◦ Entityを必ずデタッチ状態で扱えるので直感的ではある ◦ Jakarta EE 12ではコンテキストが共有される機能が追加予定 ▪ Spring Data JPAと同じ使い勝手を求めるなら・・・ 詳細についてはJakarta EE&MicroProfileセミナー「待望のJakarta EE 12最 新動向！データアクセス新仕様＆ついに標準化されるJakarta MVCを学ぶ」 の景井さんの資料を参照 51 https://jpn.nec.com/webotx/download/event/JakartaEE12_DataAccess.pdf Jakarta EE 11で追加された Jakarta Data 1.0を試す - CLOVER🍀 https://kazuhira-r.hatenablog.com/entry/2026/06/28/205548
52. JDBC/サードパーティライブラリ • • • 52 JDBCを直接書く/Mybatisなどを使用 Springで使用しているライブラリがCDIに対応しているならそのまま使用 できるはず DBライブラリに致命的な脆弱性がでることは考えにくい
53. Hibernate Panache • • • QuarkusでサポートされるHibernate(JPAライブラリ)拡張 getter/setterのいらないEntity Active RecordパターンやRepositoryパターンのグルーコードの自動生 成が可能 53 https://ja.quarkus.io/guides/hibernate-orm-panache/
54. セキュリティ (Spring Securityからの移行) 54
55. SSO、認証認可、ユーザーログイン • • • Jakarta EE 10でOpenID ConnectやOAuth2が標準対応 ◦ Jakarta Security ◦ form認証とかも作れる ServletFilter/JAX-RS FIlterを使用した独自実装も可能 Quarkusは独自実装 ◦ Quarkus Security 55 https://jakarta.ee/specifications/security/3.0/jakarta-security-spec-3.0.html https://ja.quarkus.io/guides/security-authentication-mechanisms/
56. CSRF対策 • • Jakarta EEでは統一されたCSRF対策は存在しない JSFやJakarta MVCなどそれぞれの仕様に定義された実装を行う必要 がある Jakarta MVCの場合 56 https://www.docswell.com/s/MasatoshiTada/53J7RY-jakarta-mvc#p33
57. AI 57
58. Jakarta EEサーバー: Jakarta Agentic Artificial Intelligence • • • Jakarta Agentic Artificial Intelligenceという名 前で単体仕様としてリリース WebProfile/Full Platformには入っていない APサーバーに実装されるかは各ベンダーに委 ねられているため、現時点ではポータビリティ は期待できない 詳細は、Jakarta EE&MicroProfileセミナー 「Jakarta CDI特集(実践的活用方法とAI領域への 拡張)」の数村さんの資料を参照。 58 https://jakarta.ee/ja/specifications/agentic-ai/ https://speakerdeck.com/kazumura/langchain4jtoha-wei-wei-ulangchain4j-cdi
59. Quarkus: Quarkus LangChain4j • • • 59 https://docs.quarkiverse.io/quarkus-langchain4j/dev/index.html https://qiita.com/autonomura/items/f1462e5689d9d643a1ce Quarkusの独自実装 QuarkusからLangChain4jを呼び出す SpringからLangChain4jを使ってるならあまり 違和感はないかと
60. 設定ファイル 60
61. Jakarta EEは統一されたapplication.propertiesは存在しない • • 61 Jakarta EEでは設定ファイルの読み込みが仕様化されていない ◦ APサーバーごとにまちまち ◦ 環境変数の取り扱いも違う場合がある ◦ 今後共通化予定(Springに似た感じになる予定) Quarkusではapplication.propertiesが存在して、そこに設定を書く ◦ 環境変数なども基本的にSpringと同じ
62. バッチ (Spring Batchからの移行) 62
63. Jakarta Batch/jBatch/JSR-352 ※全部同じもの 個人的にはお勧めしません • • • • JSR 352（Batch Applications for the Java Platform） ◦ Spring Batchをベースに仕様化 ◦ なんならSpring Batchも対応している Jakarta EEの思想が大きなサーバーの中で何でも動かすなので、バッ チなのにJakarta EEサーバー自体を動作させる ◦ スタンドアローンで動かす方法もあるけど・・・ 脱Springをしたい理由が脆弱性対策の場合は優先度低で対応 ◦ バッチ処理なら直接外部から狙われるものではないはず (どうしても)移行が必要ならリアルタイム化処理などのバッチ解体も検討 すべき 63 https://blog1.mammb.com/entry/2015/03/03/223006 https://yoshio3.com/2014/02/18/jbatchjsr-352-on-java-se-%E7%92%B0%E5%A2%83/ https://ik.am/entries/222
64. そのほか 64
65. 富士通さんによる移行ガイド 富士通さんも移行ガイドを作成しています。 65 https://docs.fujitsu/documents/002474/enterprise-application-platform-migrate-to-jakartaee.pdf
66. まとめ 66
67. Spring Bootから Jakarta EE/MicroProfileへの移行 • • SpringからJakarta EE/MPへの移行にはいくつかの理由がある ◦ セキュリティ対策、長期サポートなど ▪ Jakarta EE準拠サーバーへの移行がおすすめ ◦ 速度(脱Servlet)など ▪ MicroProfile準拠サーバー(Quarkusなど)への移行がおすす め AIを使う事でフレームワークの移行が比較的簡単に ◦ この後のセッションで！ 67 https://ja.quarkus.io/guides/hibernate-orm-panache/
68. Thank you Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. linkedin.com/company/red-hat youtube.com/@redhat facebook.com/redhat x.com/RedHat 68