知ってちょっと得する？Javaの死語の世界

春ですね。会社や学校で新しくJava言語を覚え始める人も多いかと思います。今から始める人も多いそんなJavaですが歴史はそれなりに深いため、今では使われなくなった用語や別のものに置き換わった用語が未だにネットに出てきたりします。

Javaを昔からやっているおじさんな人たちはそんな昔の用語がでてきてもスルーしたり他の用語に脳内変換できたりしますが、始めたばかりの人はそうはいかないと思います。そんな死語となった用語に消耗させられないためにも、今回は今でも見かける代表的な3つの死語について、なぜその用語が死語となったのかとその対処法について説明してみます。

なお、Javaの歴史教科書ではないため、歴史的なところはザックリと少しのユーモアを込めて説明しますので、そんなノリで見ていただければと思います。

トップバッターはやっぱりこれでしょう！ということでJ2SEです。これは今でいうJava Standard Edition(Java SE)そのものですが、大昔はJava2 Standard Editionと呼ばれており、それを略したのがJ2SEとなります。そしてこのネーミングの一番罪深いところは”Java2”の部分です。

Javaのバージョンは1990年代後半から1.0→1.1→1.2と進化してきましたが、この"Java2"の2はJava1.2以降のバージョンを指すものでした^[1]。

ではなぜJava1.2以降をJava2としたかというと、Java1.2ではListやMapなどのCollectionフレームワークなどJavaの機能が大幅に拡張されまたした。このため、Java1.1と1.2は別物だぞ！という意味を込めてJava2という新たな用語を作り、それまでのバージョンと区別できるようにJava1.2以降のStandard EditionをJava2 Standard Edition、つまりJ2SEとしました。

J2SEの用語はJavaの1.5からJava SE 5（または5.0）となったのを機に使われなくなりましたが、JavaのバージョンはJava9まではJava 1.8といったりJava8といったりで、混沌が続きました。

• 現在はこの用語を覚える必要はなく、使ってもいけません、絶対
• もし昔のドキュメント等でこの用語がでてきたら「今でいうJava SEのことだな」程度で脳内変換しましょう
• 求人募集でJ2SEの用語を見てしまった場合、近づいてはいけません（みなまで言いませんが、察してください）

次の死語としてJ2EEは外せません。先ほどのJ2SEとセットで非常に良く使われましたし、今でも見かけたりします。

Javaには先ほど説明したStandard Editionの他にServlet APIなどのエンタープライズなアプリケーションを作るために必要なAPI^[2]を定義、収録したEnterprise Editionがあり、その基盤はStandard Editionとなります。

と、ここまで言えばお分かりかと思いますが、J2EEとはJava2 Platform, Enterprise Editionのことで、意味的にはJava2以降のStandard Editionを基盤としたEnterprise Editionのことになります。

J2EEのバージョンはJ2SEと同様に、J2EE 1.2→1.3→1.4と続きましたが、J2SEがJavaの1.5からJava SE 5.0となったのを機に、J2EEも1.4以降からはJava EE 5といったようにJava EEに置き換わり、今では使われることはなくなりました。

なお、Java EEは現在ではJakarta EEに変わっています。EEバージョンと名称の変遷の詳細は後述のコラムを見てもらえればと思いますが、Java EE 7やJava EE 8 辺りはまだ現役でバリバリ使われていたりするため、Java EEの用語はJakarta EEに置き換わった現在でも（死語ではなく）普通に利用されています。

• 2020年代も半ばになろうかという現代でJ2EEの用語を知っておく必要はありません
• Spring MVCなどの話題の中で「J2EEのServletｶﾞｰ」とか大きな声でいうオジサンがいたら「今はJakarta EEですよ」と教えてあげるとあなたの株も上がるかもです。が、言い方を間違えるとネチネチと反撃を食らう可能性もあるので言い方には注意しましょう
• 昔のドキュメント等でこの用語がでてきたらJ2SEと同じように「今でいうJakarta EE(Java EE)のことだな」程度で脳内変換しましょう
• J2SEよりもJ2EEの用語は求人募集で未だによく見ます。さすがにこの時代に本当にJ2EEを使った開発をしているとは思えないので、単に求人募集のページを更新していないだけだと思います。が、この用語を未だそのままにしている会社は推して知るべしなので、避けるのが無難です

J2EEときたら次にはJ2EEの代名詞、ザ・J2EEともいうべき当時一世を風靡した？EJBを忘れてはいけません。

EJBはその名もEnterprise Java Beansというように、J2EEに含まれるエンタープライズなJava Beanを作るための技術です。当時はオブジェクトを分散配置し、それらを協調動作させてアプリケーションの機能を実現する分散オブジェクト技術が最も崇高で価値があるものでした。

しかし、J2EEが登場するまでJavaにはRMIなどのスッピンの分散オブジェクト技術はありましたが、トランザクションや分散オブジェクトの検索といった業務アプリケーションで必須となる技術とは統合されておらず、一体としていい感じで使うことはできませんでした。このため、J2EEがでるまでは「Javaはオモチャだよね」や「Javaで本格的な業務アプリケーションは作れないよね」などと（ほんとにお前ちゃんと分かってるのか！？と言いたくなるような一部の意識高い系の方々から）揶揄されていました。

そのような中、鳴り物入りで登場したのがEJBです。EJBには（これまた当時は崇高な技術とあがめられていた）分散トランザクションを実現するJTAや先ほどの分散オブジェクトの検索を行うJNDIなど、それ１つをとっても重厚長大な仕様たちと多方面に渡り統合が行われ、本格的な業務アプリケーションを作るには十分と言えるものでした。

が、しかし、EJBは高機能である反面、あまりにも重厚長大で難しすぎ使いこなすのがとても難しい代物となっていました。１例を挙げると基盤が分散オブジェクトのため、お約束のインターフェースや基底クラスを継承した上に、Javaのコンパイルとは別にクライアントとサーバーに配置するスタブとスケルトンを生成するejbcなどの手順が必要でした。

私も当時サンマイクロ様がこれからはEJBです！というので、それを疑いもなくご神託のように受け取り、せっせと寝る間も惜しんで日々勉強と分散オブジェクトの地獄のデバッグに励んでいました。が！ある時ふと気が付きました「そもそもEJBってなにがそんなに嬉しいんだっけ？」と。

EJBの売りは「EJBでオブジェクトを分散させて、スケーラブルで堅牢なシステムが作れます！そして、EJBはJ2EE仕様に則ったEJBコンテナであればどこでも動きます。なので、このコンポーネント化技術を基盤とすることで自分たちが作ったビジネスコンポーネント(EJB)を流通させることができます！」といったものでした。

しかし、そもそも大多数のアプリはそれほど堅牢である必要もなく、また、必要な場合はロードバランサなど別の手段を使って実現することもできました。そしてさらに、AアプリのビジネスコンポーネントをそのままBアプリの業務で使えるなんてことはありません。

といったことで、EJBのコンセプトやモノは良かったのですが、Javaで作る多くのアプリには余りにもオーバースペックで、そのうち何人かのエンジニアが「サンマイクロ様がこれからはEJBだぜぇ～と言っているけど、これって誰得？」と薄々思うようになってきました。

そんな中、颯爽と登場したのが、今ではデファクトスタンダードになっているSpring Frameworkです。ロッドジョンソンが書籍「Expert One-to-One J2EE Development without EJB」の中で「EJBでやろうとしていることって、別にもっと簡単にできるよね。というかEJBって要らなくね？」というメッセージとともにそれを実現するフレームワークとしてSpring Frameworkの原型を紹介しました。この書籍とSpringの登場により、それまであったEJB信仰はあっという間に駆逐され、Javaのエンタープライズアプリケーションの世界が瞬く間にSpring色に塗り替わりました。

私もこの本を読みましたが、当時、例外はチェック例外を使うべきで、非チェック例外を使うことは異端とされている中で「チェック例外って変更に弱いし、コードが冗長になるので、例外は非チェック例外を使うべきだ！」と大きな声でいっているのを見て、チェック例外で苦しめられていた自分としては、とても爽快な気分になったのを記憶しています。

そんなこんなで、EJBはSpring Frameworkに見事なほどに駆逐され、使われることがなくなりました。その後、Java EE 5で取り込まれたEJB3で少しは簡単に使えるようになりましたが、Spring Frameworkの便利さには到底及ばないものでした。

EJBの仕様は現在でもJakarta EEに含まれていますが、Jakarta EEにおけるコンポーネント化技術の主役は現在はCDIに移っており、EJBはその役目を終えています。というと勝手に終わりにするな！と言われる方もいるかもしれませんが、ぶっちゃけ、EJBを使う理由はないですよね？

• 中身も含めこれからEJBを理解する必要は全くありません。EJBを勉強するくらいならCDIを学びましょう
• 唯一、覚える必要があるとしたらEJBを使った現行アプリを保守しなければならないときです
• 今では使われることはなくなりましたがEJBには分散オブジェクトや分散トランザクション、トランザクションモニターなど、エンジニアとしては知っておいて損はない要素技術が多く含まれています
• 「なぜ今さらEJBの保守をやらなければならないんだ・・・」とガッカリする気持ちは分かりますが、折角なので、EJBに含まれる要素技術を覚える貴重なチャンスだと思って前向きに取り組みましょう。キッと基礎力の付いたエンジニアにステップアップできると思います

紹介したい死語は他にもMVC2やPOJOなどもあったりしますが、記事が長くなってしまったので、今回はこちらで終わりにします。機会があればまた続きを紹介したいと思います。