今回、サンプルアプリケーションを作っていく上で利用する 「Webアプリケーションフレームワーク」には、「Spring Boot」を使用します。 Spring Bootは、「Jakarta EE」の規約に乗っ取ったアプリケーションのための 「フレームワーク」である「Spring Framework」に、「Jakarta EEコンテナ」を 組み込んでしまい、単独で「Webアプリケーション」が「Webサーバ」として動作できるようになっています。
・・・上の説明を読んで、次から次へと聞いたことがない言葉が出てきて 悲しい気持ちになった方も多いでしょう。そうですよね、わかります。 わからんことをわからん言葉で説明されてもね・・・。 これらすべてのことを理解する必要はありません。 歴史的経緯から生じた、不必要な複雑さにまみれていますが、本質はそれほど複雑ではありません。 簡単に、現在の視点から整理してまとめてみましょう。
まずは、Webサーバについて説明しましょう。皆さんがブラウザでWebを見ているとき、 URLの最後が「hoge.html」のようなHTMLファイルになっている場合、それは 世界のどこかのコンピュータのどこかの場所にあるhoge.htmlファイルの中身を見ています。 URLはその「どこか」を指定するためのルールです。URLのLはLocationのL。
Webサーバは、URLで指定されたファイルを読み取って、中身をネットワーク経由で こちらに送ってくれるプログラムのことです。 有名なところでは、Apahce HTTP ServerとかNginx(「えんじんえっくす」と読みます)とかですね。
しかし、おいてあるHTMLファイルを読むだけだとつまらないです。 そこで、ファイルの代わりにプログラムを指定できるようにしました。 そのプログラムは実行結果をHTMLの形式で出力し、Webサーバは それをユーザーにファイルの中身を返すのと同じように返します。
これで、ユーザーは世界のどこかのコンピュータのどこかの場所にあるプログラムを実行し、 その結果を受け取ることができるようになりました。 このプログラムのことをWebアプリケーションといいます。
大事なことは、今、WebサーバとWebアプリケーションは別々のプログラムということです。 多くのユーザーがアクセスした場合、Webサーバは1つでOKですが、 Webアプリケーションはユーザーがアクセスした数だけ起動されています。 例えば、1000人が同時にそのサイトにアクセスすると、1000個のプログラムが起動します。 規模が小さいうちはこれでも大丈夫ですが、大きなサイトを作るには工夫が必要そうです。
さて、WebアプリケーションをJavaで作ろうとした場合について考えましょう。
Javaのプログラムを動かすJVM(Java Virtual Machine)はかなり大きいプログラムです。 仮想マシンですからね。これがアクセスしてきたユーザー分だけ起動されたらたまりません。
そこで、JavaでWebアプリケーションを作る場合には、 1つのJVMの中でWebサーバとWebアプリケーションの両方を動かすことにしました。 こういう形式でJavaのClassを作っておけば、Javaで作られたWebサーバが それをルールに従って呼び出してくれるという仕組みを作りました。 たくさんのユーザーが同時にアクセスした場合、 JVMの中にスレッドという処理を並行して動作させる仕組みを利用します。
この規格のことをJava EE(Java Enterprise Edition)と呼ぶことにしました。 これと区別して、通常のJava言語の仕様のことは、 Java SE(Standard Edition)と呼ぶことにしました。
そして、Webサーバ機能を持ち、特定の形式で書かれたJavaのコードにURLを 紐付けて呼び出してくれるプログラムのことをJava EEコンテナと呼びます。 Java EEは後からかなりいろんな仕様をぶち込んだ大きな規格になり、 それをすべてちゃんと実装したJava EEコンテナも、かなり大きなプログラムになりました。 有名なところではOSSのTomcat、IBMのWebSphere、最近流行の軽量タイプのQuarkusなどがあります。 ちなみに「コンテナ」という名前になってますが、いわゆるDockerに端を発する仮想化技術とは 何の関係もありません。
さて、「あれ？Jakarta EEの話だったんじゃなかったっけ？ Java EEとJakarta EEはどういう関係？」と思われたでしょう。結論から言うと、同じです。 名前がちょいちょい変わっているというだけです。
Java EEが出来た頃のJavaは、最初に出たJavaを大幅に改善した1.2というバージョンでした。 これを「めっちゃ良くなったぜ」という気持ちを込めてJava2と呼んでいたので、 最初はこの規格はJ2EE(Java2 Enterprise Edition)と名付けられました。
しかし、Java2は1.3, 1.4とバージョンを上げていき、いつまで「Java2」なんだという ツッコミがはいり、いつの間にか誰もJavaとしか呼ばなくなり、J2EEもJava EEになりました。
そして、Java EEはコミュニティに移管されることになりました。それ自体は良いことですが、 Javaを管理しているOracleから「ウチのものじゃなくなったので、Javaという名前は変えて」と いわれ、Jakarta EEに名前が変わりました。 Java SEはそのままなので、”Edition”の意味がよくわからなくなってしまいました。 EE以外のJakarta xEというものがあるかというと、たぶんないです。
というわけで、「J2EE = Java EE = Jakarta EE」です。同じです。
ネットの参考資料を見ると、「J2EE」「Java EE」「Jakarta EE」と 書いてあるものがあり困惑するでしょうが、すべて同じ意味です。 そこから読み取れるのは「Jakarta EEと書いてあるのは比較的新しく 書かれた資料なんだろうな」ぐらいなので気にしないでください。
さて、Jakarta EEのところで「特定の形式でJavaのClassを書けば、 それを呼び出してくれる」と書きました。
このように、「自分が書いたプログラムを呼び出してくれる他人のプログラム」のことを フレームワークといいます。 逆に、「自分が書いたプログラムから呼び出す他人のプログラム」のことは ライブラリと呼びます。 現代のプログラミングでは、他の人が書いて「使ってもいいよ」と配布されているプログラムが 多数あり、それをみんなバンバン使っているわけです。
ちなみに、「自分が書いたプログラムを呼び出してくれる他人のプログラム」のケースで、 他人のプログラムが実行の主体である場合は、自分の書いたプログラムの方を プラグインと呼びます。やってることは似てます。 何かのルールに従ったプログラムを書いておくと呼び出してもらえるという意味では同じです。
そして、Webアプリケーションフレームワークは、Webアプリケーションを作るための フレームワークです。様々なプログラミング言語にはそれぞれいろんなWebアプリケーション フレームワークが存在します。
Javaの場合には、主にJakarta EEコンテナ上で動くプログラムを作るためのフレームワークを指します。 最初期から存在するStruts、これも古くからあるSpring Framework、比較的新しい Play Frameworkなどです。 Play Frameworkが新しいといっても、比較対象がとても古いだけでかなり歴史があります。
Spring Frameworkはとても歴史あるフレームワークです。Wikipediaで調べると2002年ですから、 新入社員の方には生まれていないという人もいるかもしれません。びっくりです。 長く使われているだけあって、機能も信頼性も実績も十分です。Spring Frameworkを選んで、機能の不足に 困る事はないでしょう。
しかしながら、歴史が長いということは良いことばかりでもありません。
その間に新しい技術や考え方が生まれ、Springはそれを取込みながら成長してきました。 だからこそ、広く支持されているわけですが、それ故にどんどん複雑になっている感じは否めません。 さらに、その複雑さを初級者から見えないようにする工夫もされていて、 一見、簡単に使えるように見えるのですが、当然、その裏で動いている仕組みは複雑なままです。 何か問題が出たときに原因を調べようとするとその複雑さにいきなり直面して 途方に暮れてしまうことにもなりかねません。
しかし、歴史が長いということは互換性維持も頑張らなければいけないので、 「いったんキレイに作り直してわかりやすくしよう」とはなりません。 というか、そうしたらそれはもうSpringと呼ぶ必要がなく、別のフレームワークで良いのです。 そういう意味で、新しいフレームワークを選ぶのも良いことなのですが、 2025年現在では「Springの後を担うのは、これ！」というものがはっきりはしていません。 なので、今回はSpringを使いますが、できるだけSpringの新しい部分、わかりやすい部分だけを 使うように心がけようと思います。
Jakarta EEの大きな特徴は、システムをJakarta EEコンテナとユーザー作成プログラムが 合わさった物だとしたところでした。 Jakarta EEという規格は大きくて複雑なので、Jakarta EEコンテナも大きなプログラムでした。 Spring Frameworkで作ったWebアプリケーションもJakarta EEに則っているので、 動作にはJakarta EEコンテナが必要です。 開発するPCにJakarta EEコンテナをインストールし、動作確認するためにはJakarta EEコンテナを 起動して書いたコードをデプロイする必要がありました。
しかし、Jakarta EEの規格も徐々に整理され、あまり使わないもの、過度に複雑なものは取り除かれたり、 実装しなくてもいいかなと思われたりするようになりました。 また、ムーアの法則は健在です。各々が開発に使っているパソコンもどんどん速くなりました。 結果として、Jakarta EEコンテナも相対的に軽く小さく気軽に扱えるサイズになりました。
そうなってくると、わざわざパソコンにインストールする必要は ないのではないかと考えるようになりました。 つまり、Jakarta EEコンテナも同じJavaで書いたプログラムなのだから、 インストールするのではなく、ライブラリとして自分が書いたプログラムに取り込んでしまい、 自分の書いたプログラムを実行するときにコンテナを実行すればよいわけです。 昔のコンテナは大きく重かったので、自分のプログラムサイズが馬鹿でかくなったり、 起動がいちいち遅くなったりする心配をしていましたが、 今や、そんなことを気にしなければいけないほど、Jakarta EEコンテナは特別に大きくも重くも なくなったのです。
Spring FrameworkにJakarta EEコンテナを取り込んでしまえば、 両者のつながりを密接にすることも出来ます。 開発時に便利な機能をJakarta EEコンテナの機能を使って実現することもできるようになります。 このように、Jakarta EEコンテナを取り込んでしまったSpring Frameworkのことを Spring Bootと呼びます。
従って、Spring Bootはプログラムの起動方法や開発管理のやり方などはSpring Frameworkを使った 以前の開発と変化したところがありますが、Spring Frameworkを使ってコードを書くことは変わりません。 また、Spring Bootを使っていても、開発したものを別のJakarta EEコンテナで動作させることも、 もちろんできます。
非常に便利なので、本書の中でもSpring Bootを使っていきます。
コンテナいらずの手軽さが人気のSpring Bootですが、コンテナを取り込んだことにより、 複雑なSpring Frameworkにさらに複雑なものを追加してしまった気もします。 もともとコンテナは必要だったので本質的にはたいして変わらないのですが、 初学者が「これはSpring Frameworkの機能の話なのか、Spring Bootに特有の話なのか」が わかりづらくなり、調べ物が難しくなったというのは事実でしょう。 ここは初学者が注意するべきポイントです。
本書では、ソフトウェアの1次資料を参照することを推奨しています。
知りたいことを「ググる」と個別にいろいろな記事が見つかると思います。 イマドキならAIに質問すると、ピンポイントに答えが返ってきます。 これらは非常に便利ですし、私もよく使います。AI、ホントにすごい。
ただし、このような個別の知識はなかなか自分の中で体系づけられて理解に至らない物です。 また、ググって見つけた記事やAIが教えてくれる情報は、真偽が怪しい物も多いです。 なので、信頼できる情報で確認する習慣を付けて下さい。
では、信頼できる情報とはなんでしょうか。それは、1次情報です。 そのソフトウェアの開発元が用意しているドキュメントにあたることを基本としてください。 とはいえ、それを見つけるのも難しいし、たくさんあるドキュメントの どれが1次情報で、どれが信頼出来るものなのかが、最初はよくわからないと思います。 この文書では、どの文書を読むべきで、たくさんあるドキュメントのどこを 読めば良いのかをガイドします
(今日はここまで)