Java Webフレームワークを選ぶ 続き

ひがさんからコメントくるとは思わなかった。はてなってコワイ。SAStrutsのキーワード巡回してるんだなあ。すごいなあ。

で、書き逃げできない気分になってきたので、続き。いくつかのフレームワークについて思うこと。選択肢になりそうなフレームワークのピックアップは独断。もちろん私の選択はだいぶ思想が偏っています。参考にはたぶんなりません。

Struts

最初にJakartaにアップされた頃からウォッチしてて（実際使い始めたのはもうすこし後だけど）まあ何ていうか何処で何やってるのかたぶんほとんど全部把握してる気がする。これの使い方教えて給料もらってたころがあったくらい。出始めからダサイとは言われ続けてたような気はするけど落とし所は当時として良かったよね。広く使われたのも今となっては納得。
でももうStrutsばっかしてると腐る。私が。

S2Struts

2年前のプロジェクトで使わせてもらいました。まあActionへの自動バインディングしか使ってなかったけど。今考えるとRequestProcessorだけ自作すればすんだんだよなあと思う。当時Strutsをだいぶハックして使っていたので、POJO化のほうはそれとの兼ね合いで使わなかった。SAStrutsのわりを食ってかわいそうな子にという印象（泣）

SAStruts

政治的にも通しやすいし使えると思う。現実的な落とし所として悪くないよね。数人でもチーム組んで開発するプロジェクトだったらメンバーのレベルにもよると思うけど今私これ選びます。やっぱStrutsの名前ついてるだけで人員の確保とスタートアップが楽なのが現実。でもむりやり感がないかなあ。。。

Cubby

で、Cubby。ひがさんがSAStrutsでやろうとしてそうなことがシンプルに軽量に実装されてるという印象。Strutsから入った人はすんなり移行できるんじゃないだろうか。MVC（この言葉きらいというか違うとおもうが）だし。あとMayaaがおもしろそう。個人的に次点。

Teeda

ごめんなさい。ほんとJSFに対する食わず嫌いというか苦手意識というか。JSFがJCPに最初に登場したときの期待感と実装を最初に見たときの絶望感とのギャップは異常。

Click

ここらから毛色が変わってくる。イベント駆動に近い形を実現していてMVC(この言ry)とオサラバできる。実装するコードがちょっとJavaっぽくなる。Velocityがデフォルトでテンプレートエンジンってのも個人的にはやりやすいけど今のPOHPが良いよねって流れからすると厳しいか。
あと見通しがよすぎるくらい軽い。その分スタートアップ時は自分で基盤をととのえていく必要があるのだろうけど、そういうのって楽しいよね。

Wicket

これがつきぬけちゃうとWicketになるという印象。クラス階層ふかすぎ。抽象化しすぎ。正直重めなフレームワークなんだけれど、どうにかぎりぎり見通せそうというか見通してやろうというかそんな気にさせてくれる。正直今一番興味あります。いちばん楽しそう。結局ミーハーなんだよね、何かといいわけしても。。。

Seam

よく出来ていると思う。もうね敵わない。手も出ない。ここまでいくと完全に使われてる感が出てしまって逆に選べないというのが正直なところ。nekopゴメンナサイ。

ちなみに私自身、世間から忌み嫌われる自社フレームワークを作ってたことがあるという黒歴史をもってたりする。それもいっとう酷いやつ。まったくもってフレームワークについていちゃもんつける資格ないわなあ。。。