システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る

【考察】Jakarta EEは見捨てられるのだろうか?

への私なりの考えをツラツラと。

はじめに

@suke_masa さんは間違っている!とかいうつもりは全くありません。
確かに、そういう考えもあると思います。
私が EEを使ってみようと思った経緯や、意固地(?)にEEを使っている背景などを自分にとっての整理も兼ねて綴っているだけです。
@suke_masa さんは Springにも Glassfish勉強会にも関わる中で感じた危機感のようなものを表現されたのだと、私は思っています。*1

結論

Java EEJakarta EE)を採用するしないはエンジニアの意向とは別
(今更)焦っても大して変わりはしない、かな?

javaxパッケージの影響

これがきっかけかな?と思います。
つまり javaxパッケージが EEとして拡張できなくなるということで、EE離れが起きるのでは?という問題提起。
パッケージに関しては、

の中の @yamadamnさんと、@khasunumaさんの返信が参考になります。

SpringとEEへの影響ですが、個人的には「Springを使っている方が影響は少ないんじゃないかな?」です。 理由は、javaxパッケージを直接使うのではなくspringパッケージでラップしているから。 EEは標準技術ということで、javaxパッケージを直接使っているという認識。 「ラップしてると影響を局所化できる云々」は、@suke_masa さんとのやり取りの通り。

なので、Java EEの延長としての Jakarta EE への移行については、拡張部分を除けば これまでのJava EE8のアップデートと同じ計画ですすめて行けば良いし、拡張部分を使うのであればベンダー謹製か自社ライブラリでラップしておけば まぁ良いんじゃないですかね?というのが雑な移行計画。もうちょっと真面目に補足すると、EEに限らず 今後のシステム移行というかシステム構築のあり方はクリーンアーキテクチャとかDDDとか、そういう設計思想や知見を活用して ドメイン知識(業務の主たる関心事)をPOJOで実装しましょうってことだと思います。今回はたまたまJava EE側の問題ですが、Spring側で今回のような問題が発生しないとは言い切れませんからね。もっといえばGraalVMまで考えるとドメイン知識の実装はJavaじゃなくても良いかもしれない。むしろStruts1系からの卒業を考える際に、そもそもフレームワーク(を含めた外部ライブラリ)から如何に影響を受けないようにするのかということを考えるべきだったのかもしれません*2。少なくとも SoRなシステムであれば。SoEは当たるか外れるか分からないものを扱うものだと思うので そこまでやるのは YAGNI として良いのですけどね。

どうでも良いけど、オレオレFWを考えてみようと思ったのも外部ライブラリの影響を局所化するためには?という思考実験の延長。 クリーンアーキテクチャとかDDDとか、そのあたりの情報を知ってライブラリをラップするというのではなくアーキテクチャー的なアプローチで解決できそうだというのを知って考え始めました。

私がEEを採用した理由と実感

Springを採用するにせよ、EEを採用するにせよ 実際のところは

言ってしまえば、Struts1系が何故採用されたのか?と実質同じ。
私は標準であるという思考停止だけど、デファクトだからというのも似たり寄ったりじゃないかと。

私は標準であることを理由に使ってみることにしました。
実際に手を動かして比較して、というところまではしませんでしたが @kikutaro_ さんが大体同じプロセスを経て EE6に至っているように思いますので、以下の記事を読んでいただければ雰囲気は伝わると思います。*3

初めてのJava EE 6開発! 最初の壁をどう乗り越えた?──最新Java EE開発“虎の穴” 第1回 菊田洋一氏 - builder by ZDNet Japan

違いとして特徴的なのは JSFJPAだと思うので、EE側の利用者としての感想。

SpringMVCは、Struts1系と同じでアクション指向だから採用されて、JSFは違ったから避けられたのかな?
テンプレート的な使い方であればJSFは使いやすいと思うし、実際、私はEEを金魚本で独学しているときに、SAStrutsの案件に関わって「EEと変わんない」というくらいの違いしか感じず。 アクション指向とコンポーネント指向という違いやライフサイクルの違いは分かるけど、そんなものと思ってしまえば、まぁそんなもの。 リクエストにたいしてレスポンスをページ単位で返却する、というWebの仕組みの範疇。
紙芝居的なWebページだったらJSFに不満ないなぁ。

ただ、JSFをjQueryMoble(とjQueryAjax)と合わせ技で動的にView更新をしたら相性の悪さを感じました。 でも、これは自分の技術力不足だと思っています。*4

率直な感想としては動的ページ(SPA)はJAX-RSを使ってJSFを中途半端に使うのは辞めた方が良いです(笑)

MyBatisのSQLを直接書ける感じが好まれてJPAは避けられたのかな?JPAのステートフルなところやJPQLのクセはあるけど、別にSQLを直接書いてはダメということもないしJDBCの延長くらいの使い方であれば別に困ることは無いんだけどなぁ。 私はそこまでリッチなこともしていないから本当の苦しみは分かっていないだけかもしれません。 MyBatisを使ったことは無いけど置き換えを考えたくなるほどでもないです*5。 正直、MyBatisにするくらいなら、S2JDBCの方が良い。なので実質後継であるDoma2の方が魅力的。 JPAを使わないんだったら、私はDoma2を選ぶなぁ*6

Springがデファクト

※あくまで自分の理解なので、間違っている可能性はあります。整理としても雑なので雰囲気だけ伝わればと思います。

  1. EE(EJB2.x系)重い、WebベースだったらServletで十分
  2. Servletを拡張したStrutsは如何でしょう?(デファクトに)
  3. DIで軽量フレームワークは如何でしょう(Spring,Seasar2*7
  4. SpringMVC、JSF、Velocity、Struts2系(群雄割拠)
  5. SAStrutsが使われる*8
  6. Java EE6(JSF2.x系、JPA の採用)登場
  7. Struts1系がEOL確定
  8. EEもSpringもStrutsからの移行先として広報
  9. 移行するならStruts1系と同じアクション指向が馴染みが良いよね。
    JavaScriptによるページ制御とアクション指向は相性がいいよね。
  10. 金魚本が出るが・・・
  11. SpringBoot1.xリリース(MyBatisも使えるよ)
  12. SAStrutsのEOL確定
  13. Springが採用されデファクト

MSのASPが標準的な扱いで、Javaの標準もそれに近しいJSFが良いのでは?みたいな話をどこかで読んだような気がしますけど曖昧です。
RoRによるEoDの影響はかなり大きかったと思います。当時の私は全く知りませんでしたが、SAStrutsJSF(Java EE6)のことを調べる過程でRoRそのものと、RoRが各言語のFWに与えた影響の大きさを知りました。 Java EE6リリースの時期を確認すると、SAStrutsと同じか ひょっとしたら先だったかもしれませんが、私の当時の認識では SAStrutsが先で EoDとしてRoRなどの影響を受けて Java EE6が出た印象です。 なので、EEを先に勉強はしていましたが、SAStrutsをベースとした開発案件を受けて勉強した際に「SAStrutsを参考にJSF2.x系は作られたんじゃないのか?」と真剣に思ったくらいです。

Java EEデファクトに なれなかったのは

  • EEは重いという印象で去って行ったユーザーが帰ってくることは無かった
  • Java EE6(EoD)にアクション指向フレームワークが標準に無かった
  • 金魚本の日本語版のリリースが遅かった。
    EEの日本語情報が少なく、SpringやSAStrutsの日本語情報は多かった
  • 日本ではMyBatisが好まれた(SQLを覚えたからそれで十分?)
  • SpringBootのインパクトが強烈だった

SpringBootが無かったらSpring自体も群雄割拠の1つであった可能性はあるのでは?と思ったりもします。 そういう意味ではSpringはJavaでありがちな「環境構築の壁」をエンジニアの甘えとせず敷居を下げてユーザーのことを考えたから一気に増えたとすると、それはPivotalの努力だと思います。 それが無ければSpringがデファクトになれたのか?それくらいStrutsSAStrutsも含めて)の影響は長きにわたるものだったという印象です。*9

ちなみに日本語情報の有無については、ちょっと微妙で MyBatisは日本語書籍は ほとんど(もしくは全く?)無いんですよね。
MyBatisが使いやすいことの証左なのかもしれませんが、でも私は使用しているプロジェクトを見る限り、そこまでの嬉しさが分かりませんでした。 あえていえば、Struts1系と同じで「iBatisを使っていて、後継のMyBatisをこれまで通り使っている」というだけじゃないの?と。もちろん使い続けたいと思わせるライブラリだというのは大前提として。

私はSpringがデファクトになった理由はJavaを採用する人にとって採用しやすかったであってSpringをエンジニアが採用したからではないと思っています。
(といいつつ、この後、前言撤回しますが。)

補助資料

Springの歴史

www.slideshare.net

SpringBootとMicroservice

モノリシックなWebアプリにおいては上述の理由であると思いますが、もう1つの波があります。 みんな大好きMicroserviceです。
色々と端折りますが、UberJarの仕組みを簡単に提供したのが SpringBootだと思っています。 EE陣営もPayaraMicroやKumuluzEEが頑張っていたと思いますが、肝心のOracleは行動が遅かったです。なんだかんだといっても「標準」のオーナーである Oracleの腰が重いと EEの仕様として標準化されません。 たった数年かもしれませんが、この出遅れは結構致命的だったと思います。

この点についてはEEからエンジニアが離れたと言っても仕方ないかなと。

それらに加えて、いずれMicroService化するのでは?Webサービスは12Factorであるべきだよね?と モノリスな設計思想を捨ててもないのに*10MicroServiceで構築する必然のないシステムでも採用していきます。

Springを採用するということ

最新技術へのキャッチアップです。エンジニアとしては嬉しい限りですね。
でも気をつけてください。Pivotalの速度感に皆さんがついていくということですよ? 当然、SpringBootは2系を使っていますよね。1系そろそろEOLですよ? マイナーバージョンアップでも逐一キャッチアップ&デリバリーをするライフサイクルを開発プロセスとして組み込んでいますよね? アジャイル開発してますよね?

嫌味に煽っているわけではなくて、それがSpringを使うことの価値観だと私は思っているということです。
Strutsデファクトだからと採用していた企業*11が、Springを採用するときに そこまで考慮していれば良いのですけれど、という杞憂です*12

EEも下位互換がすべて出来るかというと、まぁそういうことはありませんが標準仕様として 良くも悪くもたくさんの関係者がいる分、それなりに配慮はされていると思います。 本当に求めているのは新規性ですか?それとも安定性ですか?

EEを採用する理由

EEを採用する理由は標準仕様だからということ以外は正直ないと思っています。
そして、私にとって それが大切だと思っています。

ツラツラと冗長に書いてきましたが、@yoshioterada ‏さんと @kawasima さんの対談が、私の言いたいことに近しいです。

「Java EE 8」の注目機能は何か? この先、Java EEはどう進化していくべきか? 寺田佳央氏と川島義隆氏に聞いた - page2 - builder by ZDNet Japan

Jakarta EEとして標準仕様として明確になりそうな(なってる?)MicroProfileにも期待です。

スターターも出てきました。

MicroProfile Starterで選べるMicroProfile Serverを調べてみた - Challenge Java EE !

心強いですね。

EEをラップしてベンダー謹製のFWにするための土台は、改めて整いつつあると言っても良いのではないでしょうか?

改めて結論

さて、EEは見捨てられるのでしょうか?
それに対する私の認識は「EJBをきっかけに離脱したユーザーもエンジニアも ほとんど帰ってきていないんじゃないでしょうか?」です。 つまり今も昔も見捨てられ続けています。身も蓋も無いですね。

でも標準仕様の仕組みはJakarta EEとして生き残りました。
私としては ここが大事だと思っています。
上述でも引用させていただいた @ceto_tさんの

EJBの延長としてのEEへの再評価は今後も無いと思いますが、Javaによるシステム構築における選択肢として EEが選ばれることはあると思います。
個人でも私のように「デファクトStrutsXML地獄はちょっと。。良く分かんないけど、標準というものを選ぼう。」みたいな人もいるでしょう。 もしも見捨てられるとしたら、そもそもJavaでシステム構築をすること自体が見捨てられた時じゃないでしょうか(つまりSpringと競っても意味がない)。

Java SEのオープン化で、ごちゃついてしまったところはあり、それで立ち去ったユーザーもいるようですが、それも私からすれば「エンジニアが採用を見送った」ではなく「ユーザーが ごちゃごちゃしていると判断して敬遠した」だと思っています。 ライセンスやサポートへの意識が高いエンジニアが あの意味を理解できないなんてことないですよね?Linuxディストリビューションがややこしいから やっぱりWindowsServerだね、というのであれば「あっ、はい」という感じですけど*13。もし、エンジニアとして Java SEのオープン化を有償化といって判断したとしたら、うーーん、、なんだろう。。「頑張れ」かな?*14

余談

これは完全に余談ですが、今回のきっかけのtweetの私のリツイート

と @backpaper0 さんに言ってもらえたのは素直に嬉しかったです。
「うらがみさんは、カンファレンスで登壇していたり、Doma2のコミッターだったり、凄い人なんだよ!」という喜びを妻に伝えましたが反応はイマイチでしたが(笑)

なぜ、嬉しいかというと、私のJavaスキルは実質 独学であり我流です。 誰も私のコードをレビューしてくれたこともありませんし、システム構築にあたって誰かに相談することも無い状態で作り込みをしました。SIer時代では開発案件のJava実装者であったことはありません。PLとして方式を検討したり、レビューや部分修正をすることはありましたが1から構築するということはありませんでした。当然、私のコードを誰かがレビューをしてくれて指摘をされるという経験はありません。 SIerを離れる数年前くらいから書籍などで学んだ 良いコードのあり方 とかオブジェクト指向とは?みたいなことを自分で勉強し、SIerを離れてからDDDとかの知識を学びました。Java EEによるシステム構築の際も元SIerのPL経験を踏まえて「もし自分がリーダーだったら、自分のコードにどういうダメ出しをするのか」みたいな禅問答のようなことを陰々とし続けて、自社システムを構築しました。 作り切った後、当然ですが「動くものは作れたけど、なんだか美しくないなぁ」と。設計思想としてアーキテクチャとして、システムとはどうあるべきなんだろう?と考えるようになり、改めてJava EEを使いながら整理をやり直すことにしました。 あわせてEEの情報は少なかったので、独学かつ我流であれ誰かの役に立つかもしれないと思いブログで情報を垂れ流すことにしました。
とまぁ、そういう経緯もあり「実務経験があるかと」と言ってもらえたのは、独学我流ではあったけど そこまで変なことはしていないと初めて実感し、しかも自分が「すごいなぁ」と思っている方に言ってもらえたという意味で非常に嬉しかったわけです。

さいごに

余談が長くなってしまいました(笑)
EEにおけるベンダーサポート云々の話も書こうと思いましたが、ベンダーとしてSpringであれ EEであれ それ以外であれ、有償サポートを受けつつフレームワークを採用するのであれば言及する意味は無いかな?と思ってやめました。*15


*1:愛のある故の危機感的なものだと思っています

*2:とはいえ、あの時期にDDDとか、そのあたりの知見は出たばかりだったような気がしますが

*3:このプロセスで @yoshioterada ‏さんを知るのは EEあるあるな気がします

*4:独学というか我流というか相談できる人がいない辛さを感じつつ力技で対処しましたが、もっと良い対処方法はあったはずだと思っています。

*5:あくまで個人的な意見

*6:ドキュメントを読む限りの理解ですが

*7:Springをラップして自社FW(TERASOLUNA)として活用する

*8:ベンダーがラップして自社FW(https://cloud.watch.impress.co.jp/docs/release/396408.html)として活用する

*9:ちなみに、まだ生き残っているという話も最近聞きました。

*10:口が滑りました

*11:エンジニアとはあえて言いません

*12:あっ、それを嫌味というのか

*13:それはそれできちんと理解して選定しています

*14:様子を見るというのであれば理解できますけど

*15:そのレベルなら Javaそのものの採用からの話になってしまう