GlassFish → Payara を経験して見えた、WAR モデルの限界
業務では長く GlassFish を使ってきたが、最近 Payara に切り替えた。
ついでに Docker 化も進めたものの、全体として軽くなった感覚はほとんどなく、
開発時のストレスもあまり改善しなかった。
このあたりで、Java EE（Jakarta EE）が前提にしている “アプリケーションサーバ + WAR” という構造自体が、今のクラウドやコンテナ前提の世界と明らかに合っていないのでは？ と感じ始めた。
特に domain.xml のような巨大な設定ファイルをサーバ側に抱え続ける仕組みは、
ソースコードと設定が分離しすぎていて扱いにくいし、変更の見通しも悪い。
WAR と JAR の思想はそもそも別物
■ WAR（Java EE / Jakarta EE）
- Webアプリ前提のパッケージ形式
-
web.xmlに代表されるサーバ中心の設定 - アプリケーションサーバありき
- デプロイが重く、ホットリロードも遅い
- サーバ本体がでかくて起動に時間がかかる
アプリ側がサーバの思想に強く縛られるので、
環境構築からコンテナ化まで、何をやっても重さがついて回る。
■ JAR（Spring Boot 以降）
- JAR 1 個でアプリがそのまま動く
- Tomcat/Jetty を内蔵
-
java -jarで即起動 - Docker/K8s と自然に相性が良い
- DevTools で即反映
外部の巨大サーバを抱える必要がない分、扱いがとにかく軽い。
WAR がきつくなっている理由
1. アプリケーションサーバが重い
まず前提としてサーバを起動し、その上に WAR を載せる。
オンプレ時代ならまだしも、今のクラウド環境ではこの構造そのものが足かせになる。
2. デプロイとホットリロードが遅い
WAR を更新すると毎回、
- 展開
- アノテーションスキャン
- CDI/EJB/JPA の初期化
- アプリ全体の再構築
が走る。
部分的変更にも弱く、ホットデプロイは実質「毎回ほぼ再起動」。
リロードに失敗してプロセスが残ることもあり、正直つらい。
3. コンテナ化がしんどい
- サーバ丸ごとイメージ化するので重い
- 起動が遅くスケールしにくい
- Kubernetes の思想とズレている
クラウドネイティブを目指すと真っ先に引っかかるのがこの部分。
4. ローカル開発が遅い
Payara の「ホットデプロイ」は名前ほどホットではなく、
結局毎回待ち時間が発生する。
Spring Boot のように数秒で反映される世界とは別物。
JAR が主流になった理由
1. アプリがそのままサーバ
外部サーバがないぶん、再起動がとにかく速い。
2. Docker/K8s とストレートに合う
コンテナ = アプリ という構図が素直に成立する。
3. CI/CD の流れが単純
docker build → push → deploy
これで終わる。サーバにデプロイという概念自体が不要。
4. 開発サイクルが速い
サーバ側の初期化処理がないので、反映までが圧倒的に早い。
Java EE の「標準」という価値が弱くなった理由
Java EE は「標準だから安心」と言われてきたが、
実際にはバージョンが変わるたびに細かい挙動が変わりがちで、結構壊れやすい。
例を挙げると、
- JSON-B や JAX-RS の微妙な変更
- JPA の挙動差
-
javax→jakartaの全置換 - 実装ごとの非互換
“標準＝安定” というイメージとはだいぶギャップがある。
まとめ：限界を迎えているのは Payara ではなく WAR モデル
オンプレ前提の時代は、
「アプリケーションサーバ + WAR」という構造はそれなりに合理的だった。
今は状況が違う。
- クラウド
- コンテナ
- マイクロサービス
- DevOps
- 横方向スケールが前提
こういう世界観では WAR モデルそのものが足を引っ張る。
GlassFish を Payara に変えても根っこは同じで、
開発体験や運用性が劇的に良くなるわけではなかった。
最終的には、
悪いのは Payara ではなく、WAR モデルの前提構造のほうだ
という結論に落ち着いた。
自己完結型の JAR（Spring Boot）や、
そもそもランタイムが軽い Go にシフトしていく流れは、
今の時代を考えると自然だと思う。
Discussion