はじめに
2025年7月30日に開催されました、JakartaOne 2025 Japanに参加してきましたので内容をレポートします。
今回は２年ぶりの開催となり、以前はオンラインイベントであったため初のオフラインイベントとなります。全世界で見てもオフラインイベントとしての開催としては日本は最初の方とのことです。
ちなみに以前のオンラインイベントはJakartaOne Livestream - Japanという名称で、私自身オンラインで登壇させていただきました。そのころからもう3年も経とうとしています。時間の流れは早いですね。当時の動画はまだ参照できるようですので、宜しければご参照ください。
- JakartaOne Livestream - Japan https://jakartaone.org/jp/2022/japan/
今回の開催場所は品川のインターシティ内にある日本マイクロソフト社のセミナールームで開催されました。
この場所は日本Javaユーザーグループのナイトセミナーなどで何度か行ったことがあった場所でしたので迷わず行くことができました。
各セッション内容について
キーノート Jakarta EE 最新情報
富士通の数村さんによるセッションでした。数村さんはJakarta EE Speficiation Committee と MicroProfile Steering Committeeのメンバーですので、各種仕様を策定に携わっている日本では珍しい方です。
Jakarta EEの最新情報をお話される前段としてこれまでのおさらいをJava EE5の時代から最新のJakarta EE11までを説明していただきました。
最近のJakarta EEの仕様としては、コンポーネント仕様とProfile仕様、Platform仕様という３つの考え方、スコープに分かれます。コンポーネント仕様は仕様名にEEという言葉はつきません。Jakarta Batch、Jakarta Mailなどです。
Profile仕様やPlatform仕様はEEという名称が含まれ、コンポーネント仕様のセットような形になります。Jakarta EE Platform、Jakarta EE Web Profile、Jakarta EE Core Profileのような形でそれぞれの概要は以下になります。
-
Jakarta EE Platform：ほぼ全ての仕様を含む
-
Jakarta EE Web Profile：Webアプリケーションに必要な仕様を含む
-
Jakarta EE Core Profile：軽量な仕様セットでクラウドネイティブアプリケーション向け。Jakarta EE10より導入された
Jakarta EEに関する学び方は、以下サイトで学ぶことができると紹介がありました。このサイト内にあるJakarta EE Starterという初期プロジェクトを簡単に作成できるサービスは使ったことがあり知ってたのですが、他のガイドはあまり読み込んだことが無かったので別途見てみようと思います。
また、Jakarta EEを初めて学ぶ人は、このサイト内にあるJakarta EE Overview Course動画を見るのがおすすめという話もありました。これも見たことなかったので確認の上、良さそうであれば周囲のメンバーにも見れもらおうと思います。
Jakarta EE11のテーマは次の４つでした。
-
開発生産性向上
-
性能向上
-
安定性、信頼性向上
-
2年ごとのリリース
Jakarta EEになってから新規コンポーネントが追加された初めてのリリースでした。Jakarta Data1.0が追加されています。
もともとは2024年6月リリース予定だったが、要件の追加や各種トラブルもあり、2025年6月にリリースとなりました。
削除された機能として、Managed Bean、 SOAP、XML Webservice,XML Binding の４つの仕様が無くなった。ただし、これらのコンポーネント仕様がなくなるわけではなく、サポートを続けるかどうかもアプリケーションサーバー製品のベンダー次第なので利用している際にはバージョンアップなどの際に確認することが必要と感じた。
機能追加として、Validation,Persistence,ELでRecordが使えるようになった。これによりJavaBeansでのみ機能対応されていたものが、Recordでも機能享受できるということになります。Recordはイミュータブル（不変）なオブジェクトを作るものですので、バグの埋め込みが少なくなったり、コードの見通しが良くなります。
同じく、Concurrencyでバーチャルスレッドがサポートされました。Java17使う時はプラットフォームスレッドを使い、Java21で設定すればバーチャルスレッドを使うことができるようになった。周囲でも１リクエストの処理を複数並列で分岐させながら並列処理したいという声があったので、今後はこのようなことが簡単かつ軽量にできるようになるのは期待したいところです。
今後リリースされるJakarta EE12の予定の話もありました。
2026年6月リリース予定となっており、もう１年切っています。Application ClientコンテナやJNDIの非推奨化の話も出ているようなのでよく注意したいと思います。
MVCフレームワークである、Jakarta MVCもバージョンアップの際に毎回Jakarta EE Web Profileに入れないか？という話もあがっているが毎回リジェクトされているとのこと。日本国内だとMVCフレームワークを待っている人も少なからずいると思いますので、なんとか入れてくれると嬉しいなと個人的には考えています。
また、MicroProfileの仕様であるConfigについてもJakarta EEの方に入れるという話も出ているようでした。
NoSQLは入る見込みとのことです。JPAに近いかたちでNoSQLにアクセスでき、insert/delete/selectのAPIがある。JPAのようにEntityを定義して、NoSQLにアクセスすることで開発者はビジネスロジックに注力することができるとのことです。
MicroProfile最新情報としては、AI関連については仕様策定者の中でAIグループが設立されたがJavaの標準仕様として策定するのは時期尚早と判断され、何か標準仕様策定関連の意見があればlangchain4jのOSSプロジェクトに意見だしすることになったとのことでした。
またMicroProfileとJakarta EEの今後の合流について、Red Hat/IBMの両社から共同プロポーザルが今年の3月に発表とのことです。関係性、依存関係などを整理されたものになってました。多少複雑なものとなっているが、議論のたたき台として検討されている見込みとおっしゃっていました。
テクニカルセッション Spring全盛時代になぜJakarta EEで書くのか
IBM田中さんによる講演でした。
内容としては、Jakarta EEで書く必要がある背景、企業ごとのニーズなどを整理された話という形で受け止めました。
Javaは仕様があって実装があるというのが特徴であるが、Springは仕様がなく実装のみという形になっています。Springの実装に依存するためOSSではあるもののベンダーロックインが発生する懸念があるという説明でした。
また、Jakarta EEについては高い安定性と継続性、長期的な利用を前提としたエコシステムが充実しているということと、実装しているベンダー製品同士で いつまで使えるか、というサポート期間もベンダーごとに競争が働いていることもメリットとおっしゃっていました。
身近なシステムについても長寿命のシステムで、できれば同じバージョンで長い期間運用したいというニーズは多いのでこのメリットは大きいなと感じました。
保険会社におけるJakarta EEの利活用方法と今後のJava/JakartaEEへの期待
明治安田生命の寺田さんによる講演でした。
こちらの会社は日本で一番長い歴史のある生命保険会社ですが、昨年１月より明治安田生命から明治安田に社名を変えています。生命保険を超えたサービスの展開をするためということで多角化を狙っているのだなと感じました。
こちらの会社では2000年代からJavaによる開発をしてきたがその後長期間利用するシステムということもあり保守が必要、後方互換を重視する技術選定をしてきたとのことでした。
同じ金融システムというドメイン同士共感できる部分が多数ありました。
また、開発要員の集めやすさという観点でもJavaエンジニアには優位性があるとも語っておりました。
現状の困りごととしては、Jakarta EEの書籍、各社ベンダーからの研修がなくて困っているといったことや、開発ベンダーへのIT技術知識がアップデートされていないことを感じる場面が多く、啓蒙活動が必要とおっしゃっていました。ここもよく共感できました。
事例セッション POWER EGGのJakarta EE利用事例のご紹介
ディサークル松下さんによる講演でした。
2000年ごろからJ2EEを使い始め、当時はWebLogic、WebSphere、OracleAS、InterStageなど複数種類のアプリケーションサーバー製品を使い、利用コンポーネントとしてはEJB、Servlet、JSPなどを使っていたとのことでした。
その後次のバージョンとして、Java EE5でGlassfish2とInterStageを使い、EJBとJSFのコンポーネントを使っていたとのことです。私も深くJava EEを学んだのはJava EE5でGlassfish2を使っていたのでとても懐かしく感じました。
現在はUI部分はJSF（Facelets）、他システムからの通信部分としてJAX-RS、ビジネスロジックはEJB、フロント部分とビジネスロジックのつなぎのところはCDI、DBアクセス部分は基本JPAを使い性能要件が厳しいところだけJDBCを使うという設計をされていました。とても利にかなった、地に足ついた構成だなと感じました。
この会社のJakarta EEの採用理由としては、先ほどの明治安田さんの発表とも似ており、オープンでありベンダーロックインされない、長期間使い続けることができる、デファクトスタンダードであるといったところがあると語っていました。
また今後の期待としては開発生産性の向上の策を打ってほしいという話や、先ほどと同じく世の中の情報が少ないのでなんとかならないか、という話もありました。
その他Jakarta EE11のUpdate
Red Hat 瀬戸さんによる講演でした。
Jakarta EE11ではCDIの機能増強がされています。EJBの非推奨化に向けて@Scheculeなどの非同期処理がCDIで使えるようになったのと、そこの中でEJBの同機能ではなかったメソッドの戻り値で非同期処理を継続実行か停止するかを判定できるようになったと言ってました。これは便利で使ってみたいです。
また、これまでデータソースなどのアプリケーションサーバーが管理しているリソースを@Resourceでインジェクションしていたものが、CDI仕様に合わせて@Injectでインジェクションできるようになったとのことでした。これは覚えるものが減ってシンプル化を実現できているなと感じました。
Jakarta Servletの仕様追加としては、HTTP PATCHメソッドのサポートされたり、HTTP SessionをHTTP Requestのスコープ外で保持するのが明示的に禁止されたといった仕様の明確化がありました。細かいですがこのあたりも仕様で記載しないと設計ミスやトラブルのもとになるポイントなので大事だなと感じています。
また、Jakarta Facesへの追加機能としては、サーバー側のBeanに対してジェネリックパラメータが追加されていたり、組み込みスコープにおけるイベント発火の仕組みが独自仕様ではなくCDIの仕様に委譲されたというものがありました。このあたりもシンプル化が実現されているなと感じます。
各ベンダーによるセッション
ここからはベンダーセッションということで様々な製品や製品サービスごとの工夫の話を聞くことができました。詳細は割愛します。
AI駆動開発：GibHub CopilotでJakarta EEアプリの超高速開発
マイクロソフト寺田さんによる講演でした。
寺田さんは、AIの実装スピードに人間はもうとても敵わないと仰ってました。私も様々な生成AIのコーディングツール、サービスを使っているとそう感じます。
また、AIを使いこなせるかどうかが大きなポイントになり、今後個人や企業の力量の差がついてくるとも言ってました。従来のAIツールは、コード補完をしてくれる程度だったものが、最近では完全自律型のパートナーになってきている感触があるとのことです。
また、Vibe Codingのように過去は雰囲気で指示してAIにコードを書かせていたが、近では設計書から書くようにしているとのことでした。講演内では、詳細設計書とも呼んでおり弊社の開発スタイルに似ているなと感じました。
また、設計書が大きくなりすぎるとトークン数の関係でAIに一度にはインプットできないので、実装計画も書きAIに順序だてて指示しているとも言っていて参考になりました。画面投影されていた指示文書には、フェーズ１−５なども指示する形でかかれていました。これにより人が作成すると2人月か3人月ぐらいかかるエンタープライズのシステムが３日程度で開発できたと説明されており、生産性高いなと感じました。
ただし、細かいところは人間が間に入ってやらないと作りきれないとは感じていて、VSCodeなどのIDE上で人間が介入するタイミングは必要とも言ってました。確かに、過信は良くないですね。
最終的には、仕様書、設計書、手順書を用意し、１回30分ぐらいかかる指示を５回の合計2時間半でコード書いてくれたとのことでした。Javaクラス数としては60クラスとなったようです。
AIの特性を理解して使いこなすのが大事と言ってました。具体的には、嘘をつく、誤魔化す（実際には動かないコード）、ズルをする（簡単な方法を選ぶ）、壊すことがある（既存のものを壊して戻せなくなることもある）、直ぐに忘れる（コンテキスト、メモリーバンク）といったところです。
Tipsとして、マルチモーダルによるGUI修正が便利とも言ってました。AIに指示をする際にスクショとって、ここが反映されない（緑枠のところ）と指示すると内容を理解して修正してくれるようです。
最後に、最新の情報を使いたいのであれば、URLを指定して、そこから情報を取得してくるように指示するとうまくいくとも仰ってました。
寺田さんが使われていたのはGitHub Copilot関連のサービスだったので身近で使っているサービスで同じように実現できるかは分かりませんでしたが、考え方や気を付けないといけないことの概要は理解できたのでとても有意義でした。
おわりに
今回は1日のセミナーでしたが共感できる部分や得るものが多く、とても参考になりました。Jakarta EE関連の最先端の情報やユーザー事例を聞くことができて良かったです。
Discussion