NanoBananaProで「説明コスト」を一気に下げた話

以下の情報をインフォグラフィックにしてください。

==================================================
Java 8 → Java 21 に伴う「javax → jakarta 問題」の整理
==================================================

1. Java SE（JSE）と Java EE の違い
==================================================

【Java SE（Java Standard Edition）】

- Java の言語仕様・JVM・基本 API を定義する基盤
- 管理主体：Oracle（OpenJDK プロジェクトとして実装はオープン）
- JDK に含まれる
- Java 21 でもこの構造は変わっていない

主な内容：

- java.lang / java.util / java.time / java.nio など
- 暗号・SSL・管理系 API
例：
javax.crypto.*
javax.net.ssl.*
javax.management.*

※ 「javax」という名前でも、Java SE に属するものは Jakarta にはならない

【Java EE（Java Enterprise Edition）】

- Web / 業務アプリ向けのエンタープライズ API 群
- Java SE の上に乗る仕様（JSE には含まれない）
- 実装はアプリケーションサーバが提供する

主な仕様：

- Servlet
- JPA
- JAX-RS
- EJB
- CDI
- Bean Validation
- JMS など

※ アプリケーションサーバ（JBoss / TomEE / GlassFish 等）が実装を提供

==================================================
2. なぜ Java EE の javax が jakarta になったのか
==================================================

【背景】

- Java EE は元々 Oracle が管理していた
- 2017 年に Java EE 全体が Eclipse Foundation に寄贈された
- これにより Java EE は「Jakarta EE」に改称

【問題点】

- javax.* というパッケージ名の商標・管理権は Oracle が保持
- Eclipse Foundation は javax.* のまま仕様を進化させられなかった

【結果】

- Jakarta EE 9 にて、Java EE の全 API パッケージを
  javax.* → jakarta.* に全面変更
- 技術的理由というより「法務・ガバナンス上の理由」が主因
- 後方互換性はなく、再コンパイル必須の破壊的変更

例：
javax.servlet      → jakarta.servlet
javax.persistence  → jakarta.persistence
javax.ws.rs        → jakarta.ws.rs
javax.ejb          → jakarta.ejb

==================================================
3. 自分たちのアプリで影響を受ける箇所
==================================================

【影響を受ける箇所（Jakarta 問題の直撃エリア）】

- 業務アプリが Java EE 仕様 API を直接参照している箇所
- import 文が javax.*（ただし Java EE 由来の場合）

典型例：
import javax.servlet.http.HttpServletRequest;
import javax.persistence.Entity;
import javax.transaction.Transactional;
import javax.ws.rs.GET;
import javax.validation.constraints.NotNull;

→ Jakarta EE ではすべて以下に書き換えが必要

import jakarta.servlet.http.HttpServletRequest;
import jakarta.persistence.Entity;
import jakarta.transaction.Transactional;
import jakarta.ws.rs.GET;
import jakarta.validation.constraints.NotNull;

【注意点】

- Java SE に属する javax.*（例：javax.crypto）は対象外
- 設定ファイル（web.xml / persistence.xml / XML Namespace）
- JSP / JSF / TLD / annotation / reflection 文字列
  も影響対象になる場合がある

【実務での簡易判定ルール】

- import javax.xxx を見つけたら
  → 「Java EE 由来か？」を確認
  → Java EE 由来なら Jakarta 影響あり

==================================================
4. JBoss の中の「Java EE 部分」と「JBoss 固有部分」
==================================================

JBoss（WildFly）は、内部的に大きく以下の 2 つで構成される。

--------------------------------------------------

① Java EE（Jakarta EE）仕様に由来する実装

- Java EE / Jakarta EE の仕様 API を実装する部分
- Servlet / JPA / JAX-RS / CDI / EJB など
- 業務アプリが直接参照することが多い

特徴：

- Java EE 時代：javax.*
- Jakarta EE 時代：jakarta.*
- 今回の Jakarta 問題の対象はこの部分のみ

⇒ 業務システムで
「① を参照している箇所」は確実に影響あり

--------------------------------------------------

② JBoss（WildFly）固有の実装

- Java EE 仕様ではない、JBoss 独自の拡張・内部 API
- 管理・起動・ロギング・サブシステムなど

パッケージ例：
org.jboss.*
org.wildfly.*

特徴：

- javax / jakarta の影響は直接受けない
- ただし WildFly のメジャーアップグレードに伴う
  非互換や設定変更の影響は別途あり得る

⇒ Jakarta 問題としては原則対象外

==================================================
5. 全体まとめ（判断軸）
==================================================

- Java SE（JSE）は今も Oracle が管理し、Jakarta にはなっていない
- Jakarta になったのは Java EE のみ
- Java EE の仕様 API は
  javax.* → jakarta.* に全面変更された
- JBoss の中でも
  ① Java EE 仕様実装 → Jakarta 問題の対象
  ② JBoss 固有実装 → Jakarta 問題の直接対象外
- 業務アプリが
  「① Java EE 仕様 API」を参照していれば Jakarta 影響あり

この観点でソース・依存・設定を洗い出すのが
Java 8 → Java 21 移行における Jakarta 問題対応の基本となる

--------