WebLogicでHOT deploy - ひがやすを技術ブログ

WebLogic的には、FastSwapというそうですが、アプリケーションサーバを稼動させた状態で、クラスに変更を加えたときに、その変更をアプリケーションを再デプロイなしに認識する機能がWebLogicにも入るようです。
http://edocs.bea.com/wls/essex/TechPreview/pdf/FastSwap.pdf

残念なのは、変更をリフレクションでは検知できないことかな。アノテーションをつけたり、削除したりしても変更できないということなので、いまどきのアノテーションベース、リフレクションベースのフレームワークは、その恩恵を受けることができません。

JavaRebelでもそうですが、VMレベルで変更を認識することが可能でも、結局フレームワークがHOT deployに対応していないことには、どうしようもありません。
JavaRebelのSpring対応では、クラスファイルの変更を認識すると結局、Springの再起動をする必要があり、そこに時間がかかってしまうので、実質的は使えないのです。

Seasar2なみにHOT deployが実用的に機能するには、まだまだ、ほかのフレームワークは、時間がかかると思っています。
Seasar2(SAStrutsやS2JDBCを含む)がもう機能追加はしないといっているのは、ほかのフレームワークが機能的に追いつくのは、まだまだ時間がかかるだろうと思っているからです。
仮に、HOT deployで追いつかれたとしても、どこもJSFやJPAベースになるでしょうから、SAStrutsやS2JDBCの生産性の高さにはかなわないでしょう。JSFやJPAは、良くはなってきてるけど、仕様が重過ぎるからね。
JSFやJPAが普及しないのは、「そんなに悪くはないけど、教育コストがかなりかかる割には、生産性があがらない」というのが原因だと思うし、この構造は変わらないでしょう。

フレームワークは、実際に作ってみないとわからないことが多いし、実際に使ってみないと良くはなりません。
JSFやJPAは実際にコードを書く前に、あるいは実際に使う前に、仕様を決めているから、机上の理論になっちゃうんですよ。また、ベンダーが集まって仕様を決めているから、それぞれの思惑を反映した玉虫色の仕様になっちゃう。
仕様は、一人の人がばっと決めたほうが面白いものになる。ばっと作った後に、必要ならみんなで直せばいいんです。そして、実際に使った多くの声を反映させたほうがいいものになる。
今のJSFやJPAのやり方では、そこそこのものはできても、すごくクールなものは出てこないんじゃないかな。