この記事を書いた趣旨

javax.servlet と書くのは、そろそろヤメにしたい。
jakarta.servlet と書きましょう。

なんでこんな事になったのか？

@tkxlab(隆川場)様が書かれた以下の記事が、大変よく、まとまっています。

2009年サン・マイクロシステムズをオラクル社が買収しました。

docker（2013年）やKubernetes（2015年）のようなシステムの登場が大きな契機でした。エンタープライズシステム開発の将来を予見するような、エポックメイキングなプロダクトです。ただ、Oracle社の動きは鈍く、意欲も見えなかったので、これに対して、コミュニティでは、 Java EE Guardiansを結成（2016年）し、Orcle社へ働きかけました。

2017年に、Java EEがOaracle社からEclipse財団に移譲される

Javaの商標権をORACLEが持っていて、パッケージ名をjavaxからjakartaに変更しなければ、ならなかった様子です。

じゃぁORACLEは、今何をしているのか？
これは私の推測ですが、Javaのコアな部分(JavaSE)の開発に力を入れている様子です。
例１）GraalVM
例２）新しいCPUへの対応(Intel x64 → Arm → RISC-Vなど）

いつごろ変更されたのか

@miyo4(M)様の記事が良くまとまっています。

Tomcat 10から、変更になったんですかね？

私はいつごろ変更したのか

2023年06月21日に私が書いた記事が、ありました。

私は某中小企業で、社内SE兼PGをやっています。
WEBアプリも内製しています。
AWSのサーバ構築も自分でやっています。

（おそらくTomcat8.5のEOLが2024年で、その半年前ぐらいから危機感を持っていたのだと思われます）

最新技術は、microprofileで検索

(ChatGPTはめったに使わない。ググるのが好きな年寄りです）

上記の図が、わかりやすいかも知れませんが、たぶんこの記事を読んでいる方は、全く理解できないかも知れません。
（私が読んでも、実はよくわかりません（苦笑））

上記の記事を読んで、今知った事があります。

Spring Frameworkは混ぜるなキケンではなく一緒に使えません
SpringとMicroProfileでは目的を同じにした別の仕組みを基盤としているため、両者を1つのアプリケーションで共有して使う理由はありませんし、仕組みとしてもムリがあります。

上記の記事に、おすすめアプリサーバが載っています。
・OpenLiberty
・Payara
・Wildfly
・helidon
・QUARKUS

私流の簡単な説明

フロントエンドの開発がReactやVueになってしまった。
「じゃぁサーバーサイドは何するの？」「RESTful APIだけ作れればいいじゃん」
と考えた様子です。

そのため、JAX-RSが主役になりました。これはJavaでRESTful APIを作る仕組みです。

それ以外だとCDI という SpringFrameworkでいう所の依存性の注入（Dependency Injection、DI）が、マイクロプロファイルでも使えます

じゃぁServlet-APIはどうなったの？

ご安心ください！！　
まだまだ使えます。
マイクロプロファイルの外側にJavaEE互換層があるそうです。
ちなみにJavaEEもJakartaEEへと名前が変わりました。
当然パッケージ名もjavax.〜 jakarta.〜に変わっているはずです。

上記のおすすめアプリサーバのうち上３つならServletも使えるそうです。
・OpenLiberty
・Payara
・Wildfly

個人的にはWildflyしか勝たん

気に入っている点

・Tomcatと体感差がない高速起動
・アプリサーバ側にHibernate(JPA)が入っている
　（warファイルのサイズが非常に小さくなります)
・DI(CDI)が使える
・トランザクションのアノテーションも、もちろん使えます
途中で例外が発生したら、トランザクションは自動でロールバックされます。
・JAX-RSも使える（ほとんど使ってないけど）
・Mac限定ですが、サーバーのログがカラフルで綺麗です。

ちょっと気に入らない点

・sfl4jなどのログを、全部Wildflyが横取りしてしまう点
(Wildflyが吐くログ入るの中に出力されます)

その他

・ログイン機能でKeyCloakを使っているから、Wildflyも勉強したかった。
KeyCloakはWildfly上で動作しているアプリです。

Tomcatからの移行は大変でしたか？

そんな事はありません。

私が書いていたアプリは３つあり、全て移行済みです。
ちなみにJavaは Java17に移行済みです。

	アプリ１	アプリ２	アプリ３
画面数	約30画面	約20画面	約10画面
Servlet使用	有	有	有
JSP使用	有	有	有
JSPのタグリブ使用	なし	なし	過去にあった
FileUpload	なし	有	有（最近追加）
DBアクセス	MyBatis	JDBC	主にJDBC
その他	なし	POIの使用☆	HTMX.js
CSS	Bulma	手書き	Bulmaに変更中

☆POIはEXCELファイルを作るライブラリです。

ちなみにDBですが、アプリ１、アプリ２はMariaDBに移行済み。
アプリ３のみMySQL5.7が残っています。

また上記アプリはDataSourceは使っていません。
JDBCの機能でConnectionを取得するか、MyBatisの機能でセッションを取得しています。

書き換え時にハマった事

覚えているだけ書きます

アプリ２で commons-fileuploadを使っていた

CSVファイルをアップロードする部品として、commons-fileuploadを使っていた。
この部品は javax.servletに依存していました。
Wildflyに変えて、jakatra.servletの世界線に変わると当然動きません。

→ 解決方法は？
調べていた所、Servlet-APIが機能強化されており、commons-fileuploadを使わなくても、２０行ほどコードを書けば、アップロードを実現できる事がわかった。
commons-fileuploadの使用を廃止しました。
（たしか現在は、jakatra.servlet対応のcommons-fileuploadもあった筈です。
　　でももう戻る気はありませんが）

アプリ３で、JSPのタグリブを使っていた

c:out とか単純なものだったので、使うのをやめてしまいました。
web.xmlの書き方が変わっているのが、痛いです。
ただし、冒頭の3〜4行だけです。
新しく使うアプリサーバーのサンプルアプリを取得して、そのweb.xmlをベースにすると良いでしょう。
一番外側のタグだけ変わっていて、中身の書き方は基本的に変わっていません。
「JSPのタグリブを実装しているjar」は当然の事ながら javax.servletを使っています。
jakarta.servletに対応した、使いたいタグリブの新しいjarを探して、入れ替えれば使える筈です。
私は、探す時間が、もったいなかったので、やめただけです。

ちなみに、JSPの中にJavaのコードを書く事は、今でも可能です。
移植（バージョンアップ）する上で、問題はありませんでした。

まとめ

Java8 → Java11 → Java17 への変更も楽でした。

上記、豆蔵デベロッパーサイトを見る限り、私は、Spring系の技術を使っていなかったのが、幸いしていたと思います。

最近作っているアプリ（開発途中）

現在開発中のアプリはJPA(Hibernate)を使っています。
MyBatisはやめました。

今回、DataSourceをはじめて使用しました。
トランザクションはアノテーションで行えるようになりました。
CDIも積極利用できるようになりました。@Injectで、依存性注入できます。

	アプリ４
画面数	約30画面
Servlet使用	有
JSP使用	有
JSPのタグリブ使用	なし
FileUpload	有
DBアクセス	JPA
DataSource利用	有
CDI利用	有
その他	RESTful API少々
ECMAScript	バニラJS派です
CSS	Bulma

JAX-RSは「アプリ１」で、使った事があるのですが、使わない事にしました。
理由はKeyCloakをリバースプロキシー構成で使っているためです。

以下の記事との対比

@K3n_to_n17 さまが、最新技術の大変素晴らしい記事を書かれています。

ただし、

2 認証と認可の進化
JWT（JSON Web Token）と、OAuth 2.0

については、私が学習した内容とは、だいぶ違う感じがしています。

私が学習した、KeyCloak本には以下のように書かれています。

・認証は、OIDCプロトコルで行うべき
・OAuth2.0は、認可のプロトコルなので、認証で使うべきでない。

と書かれています。

とても不思議なのですが、たとえば、AWSの管理者画面にログインした時、そのURLには、oauth2とか書いてあったりするんですよねー。

OAuth2.0は認証で使うべきでない とあるのに、なぜいまだに認証にも使われている（？）のかが、よくわからない点です。

上記の「認証と認可 KeyCloak入門」という本の６．３章のリバースプロキシー構成（以下リバプロと省略）の後ろに、「アプリ用のサーバー」を配備しています。

リバプロ構成の場合、JWTを学習する必要は全くありません

(もちろん知っておいた方がいいのかも知れませんが)

Keycloak本の６．３章では、Apacheをインストールし、そのモジュールである mod_auth_openidc　をインストールします。

JWTのハンドリングは全て、mod_auth_openidcとKeycloakの間で通信を行ってくれます。
そのため、アプリ開発者は、JWTについて学習する必要はありません。

アプリ開発者が知っておくべき事は、「HTTPヘッダーからログインしたユーザーのメールアドレスを取り出す方法」のみです。

もし、グループ等の認可情報もKeyCloakに登録したい場合は、「HTTPヘッダーからログインしたユーザーのグループを取り出す方法」も知っておく必要があります。（認可・権限の話）

豆蔵デベロッパーサイトさんに戻りますと

MicroProfileがカバーする仕様の図の、右から２つめ、上から２つめに
『JWT Auth2.0』と書かれている箱があります。

これは以下の意味だと考えています。
Wildfly（やJakartaEE対応のアプリサーバー）に、『JWT Auth2.0』を有効にする設定をする。そして、Keycloakと連携するための設定が必要と思われます。
・MetadataURLの設定
・クライアントシークレットの設定
などなど。

この設定ができれば、リバプロが不要になると考えています。
・『JWT Auth2.0』がJAX-RSで書いたRESTful APIを保護してくれるようになる。
・Wildflyの『JWT Auth2.0』がやってくれるのでリバプロは不要になる。

ただし、この方法は、まだわかっておりません。

それに私の場合は、JSPによって、HTMLを返すアプリが９５％ぐらいを占めていて、５％ぐらいRESTful APIを使っているという程度なので、リバプロ構成をやめる予定はありません。

MyBatisについて

MyBatisを使っているアプリがあるんだけど、どうしようかーと思っていました。
私が知りたかった事を書いている記事がありました。

ありがとうございます！！
だいぶ先になるかも知れませんが、時間ができた時に、私もやってみたいと、思います。