ひがやすを技術ブログ

電通国際情報サービスのプログラマ

SeasarとSpringのGoogle検索

etc

世間の興味をあらわす指標にGoogleでヒットするページ数を上げることができますが､SeasarとSpringで日本でのヒット数を調べてみました。

Springの方が多いことが分かります。実際にヒットしたページを見てみるとSpringのほうが汎用的な言葉な分ノイズ(Java Computing Spring 2005など)が多少交じってますが､気にしないことにします。
Springの方が多いですね。では、この一年でヒット数はどれくらい伸びているのでしょうか。たまたま、星さんが2005/2/18に書いた記事を見つけたので､そこから引用します。http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050216/156274/?ST=itpro_print

記事だと､"Spring Framework" Javaで検索したとありますが､それだと現在でも16,200なので、spring javaで検索したと仮定しました。
2005/2/18以降に延びたヒット数は､

になります。
奇妙に前のシェアのときに書いた数字(http://d.hatena.ne.jp/higayasuo/20051228#1135737951)と一致しますが､偶然でしょう(笑)。
こういうエントリを書くとさぞかし私は、Springをライバル視しているんだろうと思う方もいらっしゃると思いますが､最近の私は､あまりそういうことを考えたことはありません。引き合いに出すのは､そのほうが分かりやすいのと、世の中が興味を持っているだろうと思っているからです。
最近の私のSpringやDIに対する見方は、また別のエントリで。

DIのゆくえ

etc

Springが今後どこへ向かうのか。もちろん、私がそんなことは分かりませんが､2.0のスペックを見るとある程度予想ができます。2.0のポイントは､

だというふうに私は思っていて､設定ファイルを重視する方向性は変わってないと判断しています。
設定ファイルはできるだけ書きたくないというのが、ユーザの大きな声だと思っていますが､「設定ファイル重要」はどうしても変えられないポリシーなんでしょう。
ユーザのニーズにこたえられないプロダクトは､使われなくなっていくだろうと予想できますが､今､急にそうならないのは､他に代替が無いので､移行しようがないということと、現在Springに慣れているのでわざわざ移行したくないという気持ちがあるためでしょう。
ただし、日本は別です。Seasar2があり、設定ファイルを書かないLess Configurationがあるため、Seasar2に流れてくるユーザがいるわけです。デファクトとLess Configurationのどちらを重要視するかでSpringとSeasar2を選ぶのかが決まってきます。現在のシェアは分かりませんが､Goolgeのヒット数を見てもSeasar2のシェアが増えつつあるというのが現状ではないでしょうか。
だからといってLess Configurationだけで優位になるとは思っていません。特に海外では､Springに慣れているユーザが多いので､現状のままだと、そのままSpringを使いつづけるユーザが多いのではないかと予想します。
DIにおけるユーザのニーズは､Less Configuration以外に「標準化」があるでしょう。この標準化を実現するのがEJB3です。使いにくい標準化だと以前のEJBのように使われないこともありますが､EJB3はそれなりに良くできているので､標準として使うに値すると思っています。
デファクトを使うのは､安心感から来ることも多いと思いますが､標準化されたものはさらに安心です。log4jとJavaのLoggingのようにデファクトが標準に勝っている場合もありますが､それはデファクトが標準より勝っている場合です。SpringとEJB3を比べた場合､Less Configurationを実現している分､EJB3のほうが使いやすいと思います。そうなれば、Less Configurationと標準化のどちらも実現しているEJB3のほうが、Springよりシェアを取る、あるいはほとんどシェアをとると考えるほうが妥当なのかなと思います。
というわけで、わたしが今Springをあまりライバル視しないのは､そのうちEJB3に負けるだろうと思っているためです。また、だからこそ、Seasar2はEJB3対応を急ピッチで進めているわけです。
SpringとEJB3のシェアがいつ逆転するのかは分かりません。EJB3のファイナルリリースはJavaOne(5/16)の前になりそうですが､その後、各実装が出てきてこなれるまでみんなが様子見しているかというと実はそうではなく､結構早いうちから使ってくるのではないかと思っています。あなたは、数ヵ月後にはもう使われなくなるという技術を採用するでしょうか。
それでは、Seasar2がEJB3の世界で生き残るためにどう考えているか。それが、次のエントリで書く「Lightweight EJB3」です。

Lightweight EJB3

Seasar EJB3

Lightweight EJB3のポイントは

  • コーディングとテストの感覚間隔をできる限り短くすること。
  • アプリケーションサーバ無しでデプロイした状態でテストができること。

だと思っています。テストを短期間でかつ隅々まで行うことが重要です。
コーディングとテストの感覚間隔を短くするためには､コンパイルしたら即テストできるようになっていなければいけません。いちいち、デプロイなんてやってられません。
また、EJB3になってモックを使ったテストは簡単にできるようになりましたが､それだけでは不十分です。だって、実際にデプロイした状態でのテストもしたいじゃないですか。そのテストもクライアントでの自動テストにのせることができれば、ビューの部分以外は、自動テストでカバーすることができます。そのためには、アプリケーションサーバ無しで､クライアントでデプロイした状態でテストできる必要があるのです。
今のアプリケーションサーバを前提にしたEJB3は、上記を達成できません。Seasar2は、上記を実現した「Lightweight EJB3」を提供します。
ただ、JBoss Embeddable EJB 3.0は、動かしてないので分かりませんが、「アプリケーションサーバ無しでデプロイした状態でテストができること」は実現できているんじゃないかと思います。JBoss EJB3とは異なる実装のようなので､クライアントでテストしてOKだったことがサーバサイドではNGになるケースも出てきそうです。まだ実験段階なのかもしれませんが、実装が統一されるといわれるJBoss5は脅威ですね。コンパイルしたら即テストが実現できているのかしら。