私がJavaのシステムで実現したいことの一つに
「運用時のクラスのホットスワップ」というものがあります。
運用を開始しているシステムで、APサーバの再起動もなく、再デプロイもなく
クラスだけを入れ替えて、メモリなどもリークしないような、
そんなホットスワップを求めています。
動的言語に全く興味がないのにDaVinci Machine（JSR292 Invoke Dynamic）を
追っているのは、ホットスワップの手段になりそうなためです。
さて、そんな要求にストレートに応えてくれそうな、このBOF。
結論から言うと、そこまでのものではありませんでした。
ソース記述 → コンパイル → パッケージング → デプロイ → テスト
→ ソース修正 → コンパイル → パッケージング → 再デプロイ → 状態更新 → テスト
、、、なんてサイクルをぐるぐる回すのは大変だから、少しでも簡略化したい。
IDEを使えば、パッケージングしなくても、デプロイしてくれる。
また、IDEには、コンパイル後に自動的に再デプロイしてくれる機能もある。
ただ、再デプロイも少し時間が掛かるので、
その時間もなくすために、ホットスワップを検討した。
（この辺りの問題意識は、Seasarの id:higayasuo さんと全く同じですね）
ずっと前から、JavaVMのデバッガインタフェースを使えば、
ロジックの一部を動的に書き換えることはできた。
（デバッグ中にソースを書き換えて動かした経験は、皆さんにもありますよね？）
ただ、デバッガインタフェースは、フィールドやメソッドの増減には対応していない。
（デバッグ中にフィールドやメソッドを追加したら、継続するか停止するかを
Eclipseに聞かれたという経験も、皆さんありますよね？）
JVM自身には（Java6までは）クラスのホットスワップ機能はないが
javaagent、j.l.instrument.ClassFileTransformer、ASMやBCELなどを
組み合わせれば、自前でホットスワップ機能を実現することができる。
その例が、JRebel、WebLogicのFastSwap、GlassFishのBeagleなどである。
、、、という感じで、Beagleのデモをして終了でした。
実際に「クラスを追加しても、再デプロイせずに動作させられる」ところまで
ドヤ顔でデモしていたのですが、会場からは全く拍手がありませんでした。
ということは、会場も「その先」、つまり、Beagleの中身の説明だったり
運用時にも利用できるようなホットスワップを期待していたということでしょうか。
日本でホットスワップと言えば、真っ先に思いつくのはSeasarですが、
今後は開発効率向上のために、WebLogicやGlassFishを利用する、
というのも選択肢として挙がってくるかも知れませんね。
