ひがやすを技術ブログ

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

シェア・ユーザ数

etc

オープンソースで､シェアやユーザ数を求めることはまず不可能です。ただ、弊社がSeasar2商用サポートを開始するに当たって､国内におけるSeasar2とSpringのシェアがどうなっているのかを、いろいろな仮定を基に組み立てた数字があるので､それを公開しておきます。うちの会社もビジネスでやる以上､私が社員だからなんて単純な理由は通用しませんから。
客観的な数字として､ダウンロード数を採用することにします。Springのダウンロード数は､http://sourceforge.net/project/stats/detail.php?group_id=73357&ugn=springframework&type=prdownload&mode=alltime&package_id=73406&release_id=0&file_id=0
Seasar2のダウンロード数は､http://sourceforge.jp/project/stats/index.php?report=months&group_id=689で調べることができます。
調査の対象は､2005/1から2005/8とします。9月以降は､Seasar2がsourceforgeからプロダクトを移行させているので､対象からはずします。この調査をしたのが､8/30日なので､若干8月は不正確ですが､今､sourceforge.netが調子悪いようなので、8/30時点の数字を使います。
ダウンロード数の合計は､Springが240,063、Seasar2が47,835です。この数字がユーザ数に比例していると仮定します。そうすると､Spring:Seasar2は約5:1になります。これが、世界におけるシェアになります。
それでは、日本に限るとどうなるでしょうか。今手元に資料が無いので､正確な名前は忘れましたが､2003年のIT白書(?)に載っていたITの市場規模は､世界全体を10とするとアメリカが5、北欧が3、日本が1になります。Springがこの市場規模に比例して日本で使われていると仮定すると､日本におけるシェアは､Spring:Seasar2=0.5:1=1:2になります。
日本においては､Seasar2がなければ、Springユーザだったであろう人が、Seasar2に流れていると思うので､上記のシェアは､Springのほうが小さくなると思われますが､その辺は無視するとします。
国内のシェアは､Seasar2:Spring=2:1というのが、いろいろな仮定を置いてますが､うちの会社ではじき出した数字です。


それでは、私がどう思っているかというと､シェアはあるに越したことは無いが､Seasar2を使ってくれるユーザの作業が効率化され､仕事で儲けていただくことが一番だと思っています。

Seasarに対する私の考え

etc

Seasarに対する私の考えは､

  • Seasarのユーザを中心とした、Seasarに関連する企業が利益を得ること。
  • Seasarのコミッタ・コントリビュータが自分の力試しをする良い場を持てるようにすること。

の2つです。技術そのものにはあまり興味がありません。ユーザにとって利益のある技術を採用したいだけです。技術よりもビジネスを重要視する考え方は､おそらく私と最もSeasar2の仕様についてはなすことの多い､小林さんが感じているんじゃないかなと思います。
逆に、上記に関連しない話(ネット上の書き込みなど)は、ほとんどスルーしています。はぶさんは、釣られすぎ(笑)。

ポストStruts

etc

今は､Strutsが出た頃と違って､Web + DI + O/R Mapperの三種の神器で使われることが多いと思うので､ポストStrutsも三種の神器の組み合わせで考える必要があると思います。まず、基準になるのは､

  • Struts + Spring + Hibernate2

今､一番ポピュラーな組み合わせでしょう。
この組み合わせを牽引したのは､Hibernate2だという風に思っています。Hibernate2をよりよく使うために、Springは良い女房役だったのではないでしょうか。
ただ3つのフレームワークとも設定ファイルの肥大化という問題を抱えていて､Next Generationがまちのぞまれているわけです。

上記のフレームワークの良い点を取り入れ､問題点を解決すべく登場したのが、JSF + EJB3です。Java EE 5の標準でもあり､多くのベンダーにサポートされています。正直､JSFもEJB3もいろいろ不満点はありますが､結構使えるレベルに達していると思っています。
SpringとEJB3を比較すると

という点で､EJB3に軍配があがるのではないでしょうか。立場上､Seasar2はSpringと比較したりしますが、私としては､EJB3のほうが怖い存在だと思っています。Springが今､世界的にシェアがあるといっても比較的早くEJB3に逆転されるというのが私の読みです。
Seasar2とEJB3との比較は後ほど行います。その前に、EJB3の動向を見てみましょう。EJB3は、JBossとOracleが先頭を走っています。この2つは､EJB3が正式にリリースされたら､ほとんど間をおかずに正式対応版をリリースしてくるのではないかと予想します。EDRの時もそうだったからです。
それでは、リリース後、どれくらいで安定するのかですが､それは正直良く分かりません。ただ、オープンソースであることなどもふまえて､JBossは比較的早期に安定版を出してくるのではないかと予想します。
それでは、Seasar2とEJB3を比較してみます。ほとんど設定がいらないというのが､Seasar2の売りで、EoDについては､Seasar2のほうが優位ですが､EJB3もそれなりに使いやすいので､EoDはさほど大きな優位にはなりません。私が重要だと思っているのは､テストのし易さと自動テストの範囲をできるだけ増やすことです。EJB3は、モックベースのテストは簡単に行えますが､実際にデプロイされた状態でのテストを行うのは､かなり面倒です。その点､Seasar2(Springも)は、デプロイされた状態でのテストも簡単に行えます。この点は､Seasar2のほうが優位になります。整理すると、

になります。じゃ、結局どうなるかというと、よほどテストにこだわらない限り､それなりに簡単で標準のEJB3になるのではないでしょうか。JBossは、Embeddable EJB 3.0というアプリケーションサーバ無しで動く、EJB3も出しています。これなら、テストも簡単です。というわけで、Seasar2もSpringも現状のままだと､EJB3に負けてしまうでしょう。
そこで、Seasar2では、JSFの実装であるTeedaとPersistence APIの実装であるKuinaを用意して､Java EE 5の標準に対応します。EJB3のSimplified APIの仕様についても、S2Containerで対応する予定です。
つまり、標準を重要視する場合でも､Seasar2ファミリーですべて揃います。しかも、アプリケーションサーバなしで動かすことができるので､テストも簡単です。Teedaについては､ブラウザを使ったテストも自動化するTeedaUnitを投入します。Kuinaについては､データベースのテストを自動化するKuinaUnitを投入します。おそらく、ほとんどの部分のテストを自動化できることでしょう。
JSFやEJB3の仕様に不満がある場合には､Seasar2の拡張機能を使うこともできます。
Teedaについては､JSPのかわりにHTMLをつかったり、KuinaにおいてはエンティティにDIやAOPを適用できるようにしたり、S2Daoのようにインターフェースだけで､EJBQLやEntityManagerへのアクセスコードを自動生成したりするような機能です。
既存との互換性ももちろん保ちます。商用サポートについても､弊社で提供するので､その点でも安心して使ってもらえると思います。なにかあれば、ホットフィックスで修正しますから。