Seamについてそろそろ本音を書いておくか

Seamは、JBossで開発されているフレームワークで、JSF、EJB3、JPAを薄く(?)結びつけるためのフレームワークです。
http://www.jboss.com/products/seam
もうそろそろ、本も出ます。
http://www.amazon.co.jp/JBoss%E5%BE%B9%E5%BA%95%E6%B4%BB%E7%94%A8%E3%82%AC%E3%82%A4%E3%83%89-%E3%83%BCJava%E3%83%BB%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%83%BBJBoss-Seam%E3%83%BBJBoss-AS-%E7%9A%86%E6%9C%AC/dp/4774133795/ref=sr_1_5?ie=UTF8&s=gateway&qid=1202878591&sr=8-5
Seamが広く受け入れられるかどうかは、私にとって非常に興味のあるところです。それは、「機能豊富なフレームワークが世の中に受け入れられるのか」という私の疑問に対して答えを出してくれるからです。
実際のSeamは、「薄く結び付けてくれる糊」というより、Seam自体も機能盛りだくさんで至れり尽くせりのフレームワークです。
それに輪をかけて、JSF、JPAといった大きな仕様のフレームワークが重なるわけです(EJB3の仕様はさほど大きくないです)。JSFの部分は、FaceletやAjax機能のおまけ付き。
機能が豊富だということは、それだけ学習コストが高いということです。高い学習コストをかけても、ペイすると開発者は判断するのか。高い学習コストを全員が払うのか、一部の開発者のみにするのか。
私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、フレームワーク全体を把握していて、残りのメンバーは「限定されたことだけやっとけ」みたいなことは好きではありません。
難しいフレームワークあるいは、機能豊富なフレームワークはそういうことになりがちなのが怖いところです。
後もう1つ気がかりなのが品質です。規模の大きいソフトウェア、複雑なソフトウェアというのは、それだけバグが入り込みやすくなります。FaceletプラスアルファのTeeda Extensionでさえ、安定するまで結構時間がかかりました。現在のJIRAはこんな感じ。
https://www.seasar.org/issues/browse/TEEDA
Teedaは、単体テストもインテグレーションテストもWebフレームワークとしては、トップクラスに行なっているはず。それでも安定するまで時間がかかったわけです。
Seamはそれほど、単体テストを重要視していないと聞いています。
http://d.hatena.ne.jp/kadoike/20070720
SeamはTeedaよりも機能豊富なので、本当に大丈夫なのか見守ってみたいと思っています。個人的には、開発者のスキルに関係なく、複雑なソフトウェアは、テストをしっかりやらないとそれなりにバグるし、デグレると思っています。
ちなみに、SeamのJIRAはこんな感じ。
http://jira.jboss.org/jira/browse/JBSEAM
Seamが成功すると、フレームワークの肥大化には、しばらく歯止めがかからなくなるでしょうね。機能豊富であることが、勝ち残るための最も重要な要因だとみんなが認めたということなので。
私の個人的な意見としては、薄いフレームワークのほうが世の中に好まれるんじゃないかと思っています。Strutsプラスアルファで、学習コストが低く、ソースコードもさらっと読めるフレームワーク。
開発者全員が、フレームワークのことを把握していて、技術的に見通しがいいフレームワーク。
この薄いフレームワーク構想を実現するために作ったのが、SAStruts, S2JDBCです。口だけでなく、さくっと作ってみる。これが「ひがやすを流」。