Seasarは3どころか2.5もなくなったらしいので適当なことを

検索したらそんなのがひっかかった。

1つ目の数字がプロダクト名であって0.1がメジャーバージョンだというのにはじめて知る。そこは収穫あったかな。

3も2.5もないということでここはひとつ4あたりで。略称がslim3とかさならないし。（違

おいらは2.xだと互換性はかなり意識してしまうから3でいいと思う人間ですけど。

それができたとしてもでも次のバージョンのときSeasar4という名前だとプロダクトが別なのか、バージョンアップなのかがわかりにくいってのがきついですね。s3なんとかというプロダクト作ったときそれs4なんとかというプロダクト名にする必要があるのかとか。

やはりプロダクト名に数字入れるのは厳しいなーとか。ロードマップがぼんやりでも見えてないと採用はしにくいなーとか。

Seasar 2.4がでてから今までの間にSpringは2.5、3.0と大幅に変わってきていて、Guiceも出ています。Java EE 6でDIコンテナも定義されてしまいました(JSR299とJSR330)。EJBも3.1になり、インターフェースが必須ではなく、war内におけるようになりました。

J2SE 5.0対応したSpring 2.5でSpringMVCは大きく姿を変えました。

あれほどxmlべったりだったSpringは3.0でxmlを一切なしでも動かせるようになりました。もちろん利用することも可能です。コードで定義したところからXMLを呼び出したりもできるので複合技も可能です。Java SE 6とJava EE 6対応を正式にうたっています。

明らかに当時とは状況が変わりすぎています。セットアップがどのコンテナも非常に容易になっている中、Seasar2はいまだに一番複雑なままです。正直周回遅れの状態です。

完全に互換性を残して作るのが無理ならSpringベースではない3にして、フルスクラッチから作った超軽量コンテナでいい気もしますね。PostConstractとかコモンアノテーションとJSR330対応と設定ファイルは従来の2.4のものを利用可能、コンテナ以外はjar分離していれば。

コンポーネントの自動登録とその制限等をうまくやって、起動時間を大幅に短縮させればコンテナ毎回起動しなおしでも十分な気がします。はまりはないですし。

あとは他のプロダクトのコネクタだけしっかり用意する。StrutsとWicketあたりあればサンプルとしては十分な気もします。DataSourceとか@Resourceで参照できるようにしてJNDIに問い合わせ、存在しなかったら、ローカルで組み立てたものから取得と自動でなっていると開発は楽そうですね。

ほかにSpringMVCのようなシンプルなMVCとJDBC4やSpringJDBCのようなシンプルな極小のDAOフレームワークあたりはあったほうがいいかもしれませんね。他のプロダクト依存一切なしで、リファレンス的なものというか。極小というのがポイントで、みんなでソースコードリーディングや拡張をどんどんしていきましょう的なシンプルなやつで良いんじゃないですかね。極一部の人だけソース読むというようなプロダクトだとメンテやサポートする際に一部の人だけに負担が掛かりがちです。Guice方面の小さいやつなんてまさにそうでしょう。たとえば主となるクラスは10個以下とかならソース読みたいという人は多いのではないでしょうか。

「追記」
もしくはDIコンテナからは完全に手を引いて、スタンドアロンや他のコンテナの上で動くWEBやDAO等フレームワークを開発するとか。そっちのほうが採用されやすい気もする。たとえばSpringは3.0になってますけど、SpringJDBCをまともに使いやすいように改良しているような状況ではないですよね。Struts 1.xとも手を切りたがっていますし、間に挟みこめる余地はあると思います。あとはWicketが互換性等で苦しみ始めてきましたので、もっと整理した綺麗なイベントドリブンなWebフレームワークとか、Javascriptとの連携はどうあるべきかとか。

でもDAOは厳しいか。海外はもういわゆるJPAを使うのが当たり前になっています。その上でベンダ固有のものを選択して使う程度で。あくまでもコアは標準APIを利用するって感じですね。完全に日本向けになるでしょう。逆に言えば、この分野は海外勢はあんまりやる気がおきていません。付け込む隙はかなり大きいともいえます。海外に打って出ないという戦略もありかなと。

正直コンテナで差別化と興味を引くことは難しいと思います。

と外野から思ったことを言いたい放題。かかわってないから適当なことを言えるという。