サーブレットを「JavaでのWebアプリケーションの基礎」として最初に勉強させるのをやめてあげてほしい

研修がはじまるという画像でサーブレット JSPの本が並んでて、サーブレットを最初に勉強させるのをやめてあげてほしいと思った話。
オブジェクト指向もそうなんだけど、現状で使わなくなっているにもかかわらず情報更新がされずオブジェクト指向やサーブレット JSPが教えられ続け本が売り続けられるという現状がある。
でももうさすがに変わってほしさ。
ただ、JSPはそこまで悪くないので、サーブレットで話を進める。(ただし、サーブレットが動かない環境ではJSPは動かない)

使われていない

まず、いまの案件の多くがSpring / Spring Bootになってて、サーブレットをさわるということは少ない。

2020年のJetBrainsの調査ではこんな感じ
https://blog.jetbrains.com/ja/idea/2020/10/a-picture-of-java-in-2020-ja/

2021年のフリーランス案件だけど、日本でこういう状況
Springというのも実際はSpring Bootってことも多いんじゃなかろうか。

https://freelance-start.com/articles/68

もちろんサーブレットを使い続けるシステムの保守案件はある。
けど、逆にサーブレットだけを勉強することでそういう保守案件に優先してまわされるようになるというのも、それはそれで・・・

自社のシステムがサーブレット JSPだから必要というのであれば、それは「JavaでのWebアプリケーションの基礎」としてではなく「自社業務のための必須知識」として教えているのでいいと思うのだけど、職業訓練として「Web開発の知識が必要だよね」というのでサーブレット JSPをやって行き先がレガシー案件優先となるのはちょっと・・・

サーブレットでのWebアプリケーションの学習は効率が悪い

最初に勉強するべきは「Webアプリケーションとはどういうものか」のはず。
そうすると、サーブレットの場合はサーブレット固有の仕様を知ることやTomcatのお守りをすることに時間をとられすぎて効率が悪い。

とくに講習の場合は時間が限られていて、そして15人から20人くらいいると、だれかが変なところではまって止まるということも少なくない。

※ 追記 7/16 もしサーブレットの勉強をするにしても、Spring Bootを使うほうが楽かも。
実はサーブレットの勉強もSpring Bootを使うほうが楽なのでは - きしだのHatena

「JavaのWebアプリケーションの基礎」ではない

誤解されがちなのが、サーブレットがJavaのWebアプリケーションの基礎というところ。
たしかにStrutsなんかはサーブレットのラッパだし、Springも多くの場合はサーブレット上で動いている。
でも、QuarkusやMicronautなど新しいフレームワークはサーブレットを使わない。Spring BootでもWebFluxを使えばサーブレットに依存しない。

「でもJava標準の場合は・・・」という人もいるかもしれないけど、Jakarta EE 10でCore Profileというのができて、ここからはサーブレットやJSPは外れている。
https://jakarta.ee/release/10/

そもそもJakarta EEはJava標準なのか、という話もあるけど、それは置いておいて。

そして、MicroProfileではCore Profileに依存しているので、ここでもサーブレットやJSPは含まれていない。
https://microprofile.io/

~~Quarkusは以前はMicroProfileに準拠していたけど、いまは違うようだ~~
Quarkusも対応していて、Compatible Implementationに載るのが遅れているだけっぽい。

Spring BootをSpring Webで使ってサーブレットに依存しても、実際にサーブレットを気にする場面もほとんどなくなっている。
もちろんサーブレットが必要になる場面はあるけど、研修でそういうエッジケースに時間をかけても忘れるし、普通にWebアプリが作れるようになるために時間をかけたほうがいいと思う。

まあ、サーブレットはJavaのWebアプリケーションの基礎ではない、という話。
※ HttpServletRequestやFilterやListenerが必須ではないという話です。依存しないというのは、そもそもHttpServletRequestがないということです。また、それが必須であると勘違いさせてしまうのもよくないんではないかと。

サーブレットとはなんだったのか

サーブレットは、サーバーの小さい断片という感じの意味でつけられた名前ですね。そしてここでは「何のサーバーか」ということは指定されてません。
実際に使うのはHttpServletだけど、これはGenericServletを継承していて、JavaDocには「プロトコルに依存しないサーブレットを定義します」と書いてあります。
そう、サーブレットはプロトコルに依存しないのです。なので、初期にはFtpServletだったりSmtpServletだったりいろいろなプロトコルに対応するサーブレットを作る人がいましたね。
ただ、そういうプロトコル非依存の仕組みなので、HTTPを扱うには煩雑すぎたりします。ひとつのエンドポイントにひとつのクラスというところからして面倒ですね。なので、何がプロトコルの話で何がサーブレットの仕組みの話なのかわかりにくくなっていて、プロトコルの理解もやりにくいです。だから、サーブレット自体がフレームワークなのに、使いにくすぎるのでその上にさらにフレームワークが必要ということになってしまってます。
そういう意味では、「Webアプリの基盤」として勉強するにはあまり適していないといえます。

Java EEとはなんだったのか

サーブレットを動かすにはサーブレットコンテナが必要、そして代表的なサーブレットコンテナがTomcatですね。
コンテナ？そうコンテナなんです。
Java EEは、いまでいうDockerやKubernetesのようなことをやりたかった技術で、単にWebフレームワークだけの仕様じゃありません。
なので、JNDIのようなネーミングサービスがあったりするわけです。リリースされなかったけど、GlassFishではサーバーの伸縮を実装しようともしてました。
つまり、warファイルはDockerイメージのようなもので、TomcatはDockerサーバーのようなもの。ということで、Tomcatやwarファイルの作成やweb.xmlやデプロイみたいな話は、Webアプリケーションを勉強したいたけなのにDockerまわりまで勉強しないといけなくなってめんどい、というのと似た状況になっていて、「効率が悪い」という話につながるのです。
いまはコンテナ機能はDockerにまかせてWebフレームワークはWebのことだけ考えればいいという感じになっていますね。
なので、JEEの仕様にはメッセージングや認証、セキュリティ機能もあったりするけど、そういうのはサイドカーなどにまかせるので不要になって、Dockerがある前提で必要なものを組み立てなおしたらMicroProfileになったという感じです。そして、MicroProfileで使ってるものをJEEから選んだものがJEE Core Profileですね。
MicroProfile、ぜんぜんMicroじゃないじゃんって思うけど、これはマイクロサービス用プロファイルという意味なのです。わかりにくいね。