掲載内容は私個人の見解であり、所属する組織の公式見解ではありません。
はじめに
私は2000年頃からJakarta EE（当時のJ2EE)に対応した富士通のアプリケーションサーバ製品の開発に携わっていますが、国内技術者とSpring Bootについて先日会話した際に「Jakarta EEって何？」という話になり、驚きました。Javaを知らない人がJakarta EEを知らないのは仕方ないとして、Springを知っている人にJakarta EEが知られていないとは、想像していなかったためです。
考えてみれば以前は日経コンピュータなどのIT技術雑誌を見れば、当たり前のようにアプリケーションサーバやJ2EE/Java EE/Jakarta EEに関する話題も多く、専門書も多くありましたが、最近では技術者の興味は生成AIなどの関心が高いため、注目度も下がっても仕方ないのかもしれません。
ただ、世間のシステムの多くは、今もなおJakarta EEのようなJavaフレームワークが支えており、技術拡張も活発です。
以上より、本投稿では現在(2025年8月)のJavaフレームワークについて整理したいと思います。本投稿の「いいね」が多ければ、Javaフレームワークの最新動向を定期的に反映していきたいと思います。
Javaフレームワークとは
Javaにはアプリケーションを開発する上で各業務固有処理の実装（ビジネスロジックと呼ぶ）に専念できるように、定型的な処理を肩代わりしてくれるJavaフレームワークが多く存在します。
優れたフレームワークを選択することで、アプリケーションの開発効率は格段に向上し、フレームワークの改善により性能改善やセキュリティ強化の恩恵を受けることが可能となります。
フレームワークを利用する際に注意が必要なのは、何かしらの避けられない理由によりフレームワークには非互換が発生する場合があります。
例えば従来提供していた機能にセキュリティ上の問題があり、修正されたことにより従来は動作した処理が動かなくなる場合があります。
最新バージョンのフレームワークや修正を適用する場合には非互換情報には注意し、影響がある場合には非互換を回避する対処が必要となります。
本記事を執筆している2025年は、Javaが登場して30年となります。
Javaフレームワークも30年間で多くのフレームワークが登場し、中には惜しまれながらもEOL(End of Life)を迎えたフレームワークも存在します。
このため、本記事では改めてJavaフレームワークについて振り返り、2025年現在の状況を記載させていただきます。
標準規約とオープンソース
オープンに公開されるJavaフレームワークには、仕様策定の経緯により大きく以下の2種類あります。
1. 標準規約
Javaには特定企業の利害に依存しないように JCP(Java Community Process) という標準化のプロセスがあります。Javaの新しい技術仕様は JSR (Java Specification Request) として提案され、標準化に関する作業が管理されます。
承認されたJSRには仕様を説明する「規約(Specification)」、規約を実現する参考の実装となる「参照実装(Reference Implementation、RI)」、規約が正しく実現されているかをチェックするテストセットである「TCK(Technology Compatibility Kit)」が提供されます。
最終的に承認されたJava技術の規約は「標準規約」と呼ばれます。
各製品プロバイダやオープンソースは、RIを参考に標準規約に準拠する実装を開発し、開発した実装に対してTCKを実行して正しく標準規約が実装されていることを確認して公開します。
この製品プロバイダやオープンソースのことをベンダ実装と呼びます。
このように標準規約でフレームワークの仕様は統一されていますが、実装は製品プロバイダが提供する製品やオープンソースとして提供されます。
API仕様は標準規約で決められますが、それを実装する製品やオープンソースの導入・環境設定・運用の方法は各実装により異なるため各マニュアルを参照する必要があります。
2.独自実装オープンソース
JCPの仕組みに乗らずに独自に進化するオープンソースとして、仕様と実装が公開されるフレームワークもあります。
Spring Frameworkのようにオープンソースとして公開され、障害修正は広く技術者からの提案を受け付けていることが一般的です。
特定企業が仕様策定や開発をリードするため、数名の技術者のポリシーが色濃く実装に反映される傾向があります。
特定企業が開発をリードするため、新しいバージョンの提供計画が公開された場合、特定企業で計画的に開発が行われてほぼ計画通りに新しいバージョンが公開される傾向があります。
それでは現在主流のJavaフレームワークについて紹介します。
Jakarta EE(J2EE、Java EE)【標準規約】
JCPによりEnterprise向けのJava標準規約として1999年に登場したのがJ2EE1.2であり、Jakarta EEの初版となる規約です。
エンタープライズ向けの標準のJava技術を集約したものであるため、Webアプリケーション向けのServletやJSP、トランザクション制御用のJTA、非同期通信用のJMSなど多くの規約が集約されています。
しかし、当初のJ2EE1.2で提供されたEJBの仕様は、非常に仕様が複雑で、ソースコードにおまじないのような処理を多く記述したり、XMLファイルに多くの設定を記述する必要がありました。
特にRMIによるリモート呼び出しを実現するEJB規約に、データベースアクセスのO/Rマッピングの機能を融合したEntity Beanを含めたことで、仕様の複雑さに拍車をかけました。
このようなJ2EE仕様に反発して後述する簡単に使えるフレームワークの登場を誘発する結果となり、後述する軽量(lightweight)なフレームワークに対して重量(heavyweight)なフレームワークと揶揄されることもありました。
しかし、2006年に名前がJ2EEからJava EEに変更されて登場した「Java EE 5」において、開発の容易性(Ease of Development)に取り組む大きな方針転換がありました。
軽量なフレームワークの良い部分を取り入れたことにより格段に使いやすさが向上しています。
2017年にJava EE技術をOracle社がEclipse Foundationに移管し、商標の問題からJava EEはJakarta EEと名前が変更になり、仕様策定や実装が完全にオープンな状況となり、活発なエンハンスが行われています。
注意が必要なのは商標の問題によって、Jakarta EE 9規約以降は規約で示される標準APIのパッケージ名も「javax」から「jakarta」というパッケージ名に変更されたため、Java EE 8／Jakarta EE 8向けに開発されたアプリケーションはパッケージ名を変更する修正が必要であることです。
アプリケーションを修正するEclipse Transformer という移植ツールも公開されています。
Jakarta EEを現在公開するのは非営利団体のEclipse Foundationであり、Eclipse Foundationに存在するJakarta EEワーキンググループの創設メンバ(Strategic Member)が、富士通、IBM、Oracle、Payara、Tomitribeの5社を中心に運営されています。
標準規約のJakarta EEに対応する製品にはIBM WebSphere LibertyやOracle WebLogic Serverがあり、オープンソースにはEclipse GlassFishやOpen Libertyなどが存在します。
2022年にはMicrosoftがJakarta EEへのワーキンググループ参加を表明しています。
国内企業の提供製品にはFujitsu Software Enterprise Application Platform/Fujitsu Software Interstage Application ServerやWebOTX Application Serverがあります。
また、Jakarta EEの実装は、各規約を実装した各オープンソースを集約している場合が多く、Servlet規約を実装したTomcatやJettyなどが代表的なオープンソースです。
富士通はJakarta EE 10規約に準拠した商用製品を最も早く提供するなど、国内のJakarta EE市場を勢力的にけん引しています。Cosminexusというアプリケーションサーバを提供していた日立がJakarta EEのワーキンググループから脱退してしまったように見えるのが残念です。
参考：Fujitsu Software Enterprise Application Platform
MicroProfile【標準規約】
MicroProfileはマイクロサービス アーキテクチャ向けのEnterprise向けJava技術を集約した標準規約です。
マイクロサービスアーキテクチャに必要なJava技術を集約しているため、Jakarta EEに含まれるJava技術も含まれています。
Jakarta EEが必要な機能をオールインワンで集約しているのに対し、MicroProfileはマイクロサービスアーキテクチャに必要な技術を厳選して集約していることが特長です。
一方で機能が少ないため、適用できる利用シーンは限定的であることに注意が必要です。
標準規約のMicroProfileに対応したオープンソースにはOpen LibertyやLibertyが存在します。
富士通が開発した国産のLauncherもMicroProfileに対応したオープンソースです。
Jakarta EEと同様に2022年にはMicrosoftがMicroProfileへのワーキンググループ参加を表明しています。
Spring Framework/Spring Boot【オープンソース】
2003年にRod Johnson氏が「Expert One-on-One J2EE Design and Development」という書籍を発表し、その書籍内で紹介されたDIとAOPを取り入れたコードを元作れたフレームワークがSpring Frameworkです。
「Spring」という名前の由来はJ2EEの冬の時代の幕開けという意味も込められたそうです。
日本語で「依存性の注入」と訳されるDI(Dependency Injection)は、開発したJavaクラスの再利用性を高める仕組みです。
例えばクラスAがデータの処理を行うためにデータベースにアクセスするクラスBを利用したい場合、手続き的な処理ではクラスAではクラスBをインスタンス化して処理を実行します。
利用するデータベースを変更するためにクラスBではなくクラスCを利用したい場合、クラスCを呼び出すようにクラスAの処理を変更する必要があります。
これをクラスAはクラスBやクラスCをインタフェースとして扱い、クラスAが依存するクラスBやクラスCのインスタンスを注入する仕組みにすることでクラスAは接続するデータベースを変更する場合にも注入されるインスタンスが変更になるだけでクラスAの処理は変更せずに再利用できます。
AOP（Aspect Oriented Programing）も開発したJavaクラスの再利用性を高める仕組みです。
Javaアプリケーションを開発する場合、開発したJavaクラスに対して横断的にログ出力処理を作り込むことがよくあります。
しかし、この横断的な処理を各Javaクラスに実装すると、ログの出力場所や出力形式などを変更する場合、各Javaクラスを変更することが必要になります。
このため、AOPではログ出力のような共通に実行される処理を助言（advice）として定義し、処理コード上は間接点（joint point）として定義して、助言と間接点をアスペクトとして定義しておくことにより、Javaクラス上は間接点さえ定義すれば、自動的に共通処理が実行される仕組みです。
ログ出力に変更があれば助言だけ変更すれば、Javaクラスは変更せず再利用できます。
上記のようなJ2EEの不人気と、DI/AOPという仕組みが受け入れられて代表的なJavaフレームワークとしてSpring Frameworkが利用されるようになりました。
しかし、Spring Frameworkはエンハンスを続けたことで機能が増大し、環境設定に時間がかかるようになりました。
この環境設定を用意にする新たなフレームワークとしてSpring Bootが公開されました。
Spring Bootはマイクロサービスアーキテクチャが注目される契機となるJames Lewis氏とMartin Fowler氏が公開したMicroservicesブログが公開された2014年と同時期に公開され、Netflixのマイクロサービスアーキテクチャでも利用されていることが知られており、現在も人気のJavaフレームワークです。
上記のような時系列で公開されたため、単に「Spring」と呼ぶ場合、Spring Frameworkのことを示すのが一般的です。
Spring BootはJakarta EE規約に含まれるServlet規約の実装上で動作する仕組みとなっており、デフォルトでは内包したTomcat上で動作するようになっています。
このため、Jakarta EEとSpring Bootは競合技術ではありますが、Spring BootはJakarta EE規約(のServlet規約)に依存した技術という側面もあります。
Jakarta EEは最初から機能が揃っているためアプリケーションが利用する機能を意識した環境構築が不要であるのに対し、Springプロジェクトのページに「Start small and use just what you need—Spring is modular by design.」と記載されているように使用する機能を組み合わせて利用する必要がある一方で利用しない機能用のリソースが利用されないため小さく始められることが特徴です。
Spring Framework/Spring BootはVMWare社が公開していましたが、2023年にVMWare社がBroadcom社に買収されたため、現在はBroadcom社が公開しています。
Spring Framework/Spring Bootはそれ自体では利益を生まないオープンソースであるため、Broadcom社が今後オープンソースコミュニティをどのような方向に導くのか気になる状況です。
MicrosoftがVMWare社との協業でSpring用のサービスとしてAzure Spring Appsサービスを提供していましたが、2028 年 3 月 31 日に完全廃止がアナウンスされたことも懸念を煽られますね。
https://learn.microsoft.com/ja-jp/azure/spring-apps/basic-standard/retirement-announcement
これを契機に開発しやすくなったJakarta EEへの移行を評価する良い機会かもしれません。
Struts【オープンソース】
Spring Frameworkが公開される前の2001年にMVCモデルを実現するフレームワークとして公開されたのがStrutsです。
MVCはWebアプリケーションを開発する際に各役割ごとにモデル(Model)、ビュー(View)、コントローラー(Controller)の3つに分け、それぞれ独立して開発するデザインパターンです。
このため、Spring Frameworkが登場した当初は、フロントエンドのWebアプリケーションはStrutsで開発し、業務処理はSpring Frameworkで開発し、データベースアクセスはiBatisで開発することを推奨する企業も多くいました。
しかし、2014年ごろからStrutsに検出された脆弱性の問題で大きな損失が出る事例が出たことから、新規プロジェクトではStrutsの採用を控える傾向にあります。
その他
上記以外にも国産でSeasarというWebアプリケーションのフレームワークも人気が高かったですが、残念ながら2016年にEOLとなりました。
Entity Beanが不評だったため、Javaのオブジェクトにリレーショナルデータベースのデータをマッピングして、オブジェクト指向でデータベースを処理できるようにするO/Rマッピングのフレームワークとして、iBatisやHibernateなども登場しました。
O/RマッピングのフレームワークはiBatisのようにApacheに移管されたり、その後に離脱してMyBatisとして新たなオープンソースとして再出発するなど激しく扱いが変わっているため、現在はJava標準規約のJPA（Jakarta EEやSpringにも含まれる）に準拠したものを選択するのが無難だと思われます。
2014年からマイクロサービスアーキテクチャが注目されるようになって、最近登場して活発に開発されているフレームワークが、少ないメモリ使用量で起動・停止も高速なQuakusやMicronautに代表されるフレームワークです。
標準規約でもMicroProfileが2016年に登場し、Jakarta EE規約もWeb機能の特化した機能セットのWeb Profileや、最小機能セットのみを集約したCore Profileという規約が登場しています。
ただ、マイクロサービスアーキテクチャは顧客のニーズに応え続けた結果として肥大化したシステムにおいて、一部のシステム改修がシステム全体に及ぶ影響が大きく顧客ニーズに素早く答えられなくなったシステムを
顧客ニーズに素早く応えられるシステムに作り直す際に有効なアーキテクチャであり、導入の失敗事例も多く存在するため安易な導入には注意が必要です。
まとめ
Javaアプリケーションによるシステムを構築する場合、システムを安定運用する上で適切なJavaフレームワークを選定することが重要です。
Eclipse Foundationでは、選定するJava技術の調査結果をJakarta EE Developer Survey Reportとして公開しています。
Eclipse Foundationが以下のページのようにアンケートを募り、収集した結果をレポートにまとめているため特定技術に偏った結果では無いと思いますが、Eclipse Foundationが実施しているアンケートのためJakarta EEに注目した技術者のアンケート結果とはなっていると思います。
https://www.agilejava.eu/2025/03/18/the-2025-jakarta-ee-developer-survey-your-voice-matters/
2025年の調査はすでに終了していますので、2026年度の調査には参加してみてはいかがでしょうか？