よく考えてみると、わかりやすい説明がほとんどないことに気づきました。戸惑っている人も多いのではないかと思ったので、あえて、誤解をおそれず、本当のところ（と思うこと）をやさしく書いてみました。（もしも勘違いや間違いなどがあれば、お知らせください。）
#Java EEのままではいけなかったの？
2017年に、Java EEがOaracle社からEclipse財団に移譲されるという記事を見て、最初に思ったことでした。今は、大分時間が経ったので、少しわかるような気がします。背景として、クラウドネイティブという大きな潮流があったことがあげられます。
docker（2013年）やKubernetes（2015年）のようなシステムの登場が大きな契機でした。エンタープライズシステム開発の将来を予見するような、エポックメイキングなプロダクトです。ただ、Oracle社の動きは鈍く、意欲も見えなかったので、これに対して、コミュニティでは、 Java EE Guardiansを結成（2016年）し、Orcle社へ働きかけました。そして、Microprofile（2016年）が登場する一方、ようやく、Java EE8も公開されることになりました。
Java界のエッジの部分で大きなパラダイムシフトが起きそうなのに、Oracle社はなかなか動かない、そういうジレンマがコミュニティの活動を巻き起こし、Jakarta EEの誕生へと向かっていくことになった大きな原因だったのでしょう。
#Java EE 8、そしてJakarta EE 8
Java EE は、バージョン5（2006年）、6（2009年）、7（2013年）とバージョンを重ね、最後がJava EE 8（2017年）でした。開発の容易さを標榜して大きな成果をあげていたJavaEEですが、EE 8は、それまでのバージョンに加えて、JSFやCDIの改良、JPAのjava8対応、HTTP2への対応、そしてセキュリティAPIの追加など小さい変更に終わりました。MVCの追加も見送りになりましたが、Eclipse財団への移譲を控えて、あえて、大きな変更を避けたということだったのでしょう。
Eclipse財団に移譲されたあと、移行作業が膨大なあまり、なかなか次のバージョンが出ませんでしたが、2019年にようやくJakarta EE 8が公開されました。しかし、何か新機能が追加されたわけではなく、Java EE 8のJakartaバージョンという位置づけです。
機能を追加するには、Oracle社との権利関係にカタを付ける必要があったので、次のEE 9は、昨年12月でした。この辺りは、コロナ禍のせいばかりではなく、Oracle社が権利に固執しすぎたように思います。ただ、なんといっても営利企業ですから、仕方のないことだったのかもしれません。
Jakarta EE 9の位置づけは？
機能的には、Jakarta EE8と変わりません。つまり、2017年のJava EE8から3年、ほぼ何も変わっていません。本当に？
いえいえ、Javax.から始まるライブラリ（Java EEのすべてのライブラリ）がなくなり、Jakarta.から始まるライブラリに置き換わっています。これが大きな変更です。jakarta EE 9はこのために作られたバージョンです。
Oracle社が、javaxライブラリの改訂を認めなかったので、新機能を追加するには、最低限、名前を変える必要があったのです。ただ、すぐに理解できるように、ライブラリの名称を変更すると、過去のプロダクトとの互換性が失われます。Jakarta EE9 の依存関係の元では、Java EEはもとより、Jakarta EE8のプロダクトもコンパイルできません。
影響は、PrimeFacesやOmniFacesなど、サードパーティのミドルウェア製品にもおよび、Jakarta EE9に対応しないと、使えないことになります（2021年1月現在、PrimeFacesは未対応のまま）。サードパーティ製品を使っているプロダクトは、その方面にも目配りが必要です。
このように、影響が大きく広範囲に及ぶので、新生Jakart EEの出発点として開発されたバージョンが、Jakarta EE 9であると言えるでしょう。ですから、失われた数年間を取り戻すJakarta EEの巻き返しは、これから始まるところです。実際、コミュニティの熱気は相当なもので、来年にもリリースされるJakarta EE 10から、怒涛の快進撃（？）が始まるのではないかと期待しています。
#これからどこへ向かうのか？
そうれは、もう、マイクロサービス化へ向かうというのが、常識的な見方です。ただ、現在、Java界に氾濫している様々な専門用語を見聞きして、驚いたりする必要はありません。まだ発展途上のジャングル状態ですが、いずれ、すっきりした体系にコモディティ化するはずです。そうでなければ、広範な活用は見込めないからです。
基本的な考え方はシンプルです。システムを小さなサービスに分けて作り、それらをまとめ上げて、大きなサービスにするということです。ですから、Jakarta REST（RESTful ウェブサービス）が開発の基本単位になるでしょう。
Jakarta RESTは、ユーザーインタフェースを持たないので、JSFアプリケーションのようなものは作れないのかというと、そうではありません。ユーザーインタフェースは、何で作ってもいいのです。もちろん、クライアントAPIというのがあるので、Javaでも作れます。JSFでも作れますし、時期バージョンでMVCシステムが入ってくると、それも大きな選択肢のひとつになるでしょう。
これまでとの大きな違いは、メンテナンスの容易さです。ひとつのサービスの守備範囲は小さく、明快に役割分担を行います。ですから、改訂しようとすると、どこをどうすべきか、コードの迷路に迷い込むことはありません。また、使い勝手はUIにかかる部分ですが、これは、それぞれ独立しているので、どうにでも作り変えられます。別な言語で書き直すことすら可能です。
いいことだらけなのですが、唯一難しいのは、サービス同士の連携で、マイクロプロファイルに含まれる部分です。この部分が、現在進行形でどんどん発展しているところです。また、最近、Jakarta EEへの統合を議論するコミュニティグループが立ち上がりました。その成果が公開される頃、次のフェーズが始まるのではないかと思います。