なんとなく思ってたSeasarの問題点をまとめてみる。
Seasarというのは、JavaのDIコンテナ+その周辺ライブラリを含めたSeasar2のことと、それらの周辺プロジェクトをとりまとめるSeasarファウンデーションのこと。どの問題がどっちの問題なのかもよくわからないので、ばくぜんとまとめた。
The Seasar Project
Seasarファウンデーション
はたから見てという視点なのだけど、実はSeasarの開発者ミーティング(という名の飲み会)にはなるべく出席してたり、内情は知ってる。けれども、Seasar2は一回も使ったことがない。チュートリアルを一度動かしたことがあるかどうか、くらい。
なので、状況は知ってるけどプロダクトは知らないという感じ。
で、昨日Seasar開発者ミーティングの後の飲み会でいろいろ言ってたら、こんなところでグダグダ言わずにブログに書けとパパにゆわれたので、書く。
メンテナンスに対する不安
一番の問題点は、Seasar2ってこれから先メンテナンスされていくの？というところだと思う。
外から見る分には、メインの開発者(に見える)ひがさん(id:higayasuo)の興味はSeasar2からSlim3に移っていて、Seasar2はもうメンテナンスされないように見える。
実際のところは、メンテナンス作業は小林さん(id:koichik)など、他の人が行っているということだったと思うので、ひがさんがslim3に専念したとしてもSeasar2の開発は続けられるはず。
メンテナンスは続けられるということはひがさんも書いてる。
http://d.hatena.ne.jp/higayasuo/20090126/1232950227
Seasarコミュニティでも、Seasar2のメンテナンスは重要だという意見になっている。
では、バグ対応などは行われるとして新規機能は取り込まれないのではないかとも思える。
けども、DIコンテナはここまでやってしまうと、実際のところ機能の追加は必要がない。やることがないからホットデプロイとかの便利機能を作ったりする。DIコンテナとしてやるべきことは、オブジェクト管理の適正化など、裏側の作業だけだと思う。そして、そういう作業はひがさんより小林さんのほうが向いているように思えるので、現在の作業体制は悪くないはず。
じゃあDIコンテナ以外の機能はというと、SAStrutsやS2JDBCはSlim3でもポーティングの必要があるとはいえ使われるので、そちら側で機能拡張があればSeasar2でも使える機能は逆ポーティングが行われるはず。
だから、メンテナンスの不安の問題は、メンテナンスが行われてないということではなくて、メンテナンスが行われているのにメッセージとして発信されていないということだと思う。
ひがさんは上にあげた以外にもちょこちょことSeasar2のメンテナンスは続けられるということをブログに書いているのだけど、やはりブログという刹那的な形態ではなく、公式サイトに常設されたメッセージとしてメンテナンスをやっていくよということを書いていないといけないと思う。
Seasar.orgのサイトを更新するという話も出ているので、その際にはメンテナンスに対するメッセージを前面に出すということが必要だと思う。
どのプロダクトを使っていいかわからない
現状では、いまからSeasarを使おうとしても、いろいろなプロダクトがあって何を使っていいかよくわからない。
特に問題なのは、いろいろな技術に対して複数プロダクトがあって、どれがどうなのかまったくわからないということだ。公式サイトでは、プレゼンテーション、永続化とコンポーネントが分類されているけど、それぞれのコンポーネントは古いものも新しいものも平等に扱われているので、違いがわからない。
Strutsを使うとしてもS2StrutsとSAStrutsがある。JSFではS2JSFとTeedaがある。データベースでもSeasarオリジナルでS2DaoとS2JDBCがありJPAを使うとしてもKuinaとS2OpenJPAがある。これでは、どのコンポーネントを組み合わせるべきかというのがわからない。
それぞれのコンポーネントの違いや、Seasar.orgとしてはどういう組み合わせが必要なのかということを、もっとメッセージとして発信しないといけないと思う。
戦略的なコンポーネント開発が弱い
現在のSeasarコミュニティでは、開発者が開発したいものを開発するというスタンスになっている。
そうするとどうしても、みんなが開発したくなるようなWebフレームワークは数が多くなり、ちょっと裏側にまわる部分は弱くなるということになってしまう。
たとえばワークフローエンジンやルールエンジンというのは、開発スタックとしては必要になると思うのだけど、トップページのプロダクト一覧にはない。sandboxにはS2BuriとS2Ebiがあるんだけど。
あとはキャッシュとか。これもsandboxにS2Cachingがあるけど、Seasar2.4対応は近日中とかになって止まってるぽい。
ただ、これは上の2点とは違って、サイトの作り方とかsandboxのプロダクトを昇格させればいいとかいう単純な問題ではない。問題は、戦略的なアイデアを出してそれを実行する・させることができる人がいないということだと思う。
これまでははぶさんがアプリケーション上の提案、ひがさんが技術的な提案をして、それをまさたかさんがまとめるという形になっていたと思う。けど、いまはそれに変わる体制というのはない。
開発者が開発したいものを開発するというボトムアップも大切だけど、戦略的にトップダウンで作るものを決めるということも大切だと思う。
こういう、戦略的に開発を行える体制を作るというのがやっぱり大切じゃなかろうか。実はこういうところが、上記のメンテナンスの不安やどのプロダクトを使っていいかわからないということにもつながっていると思う。
クラウド時代のDIコンテナ、とか。
問題点じゃないんだけど、キャッシュと書いて、やっぱりプロモーションとしては今はやりのバズワード、クラウドとか言っちゃうのも必要だよなーとか思った。
S2Cloudとか。
Seasarで管理するオブジェクトを分散キャッシュにもたせちゃうの。
まあ、なにをキャッシュにもたせるかというのはいろいろあると思うけど、とにかく分散メモリキャッシュ。
Grailsのようなものを作ってはどうか？
もうひとつ、こんなんどうよ、という点では、Spring+Hibernateに対するGrailsのような、Seasar2スタックの上に載った動的言語でのWebフレームワークがあるといいんじゃないかと。
まあ、GrailsでGroovyやられちゃったんで、Scalaとか。動的言語じゃないけど。
もともとSeasarはJavaでも動的言語と同じくらいの生産性だせるよというところをがんばっていたと思うので、動的言語に行っちゃうのはどうかというのもあるかもしれないけど。
Grailsを見て、ああいうラッパというのは大事じゃないかなと思った。
そうすると、どの組み合わせがいいの？っていう問題も解決するし。
まとめ
最後の2点は冗談としても、情報の出し方で解決できるところでどうこうなるのはもったいないと思う。少なくともメンテナンスの不安は取り除いていかないと。
サイトの構成をどうにかしないとね。
サイトに関しては自分も関わっていける部分なので、問題が解決できるような方向にもっていけるようにやっていこうと思う。
