STSにおいてGroovyデバッグサポートが向上した
SpringSource Team Blog]によれば、STS 2.5.1では、EclipseにおけるGroovyデバッグサポートの機能が向上しているようです。STSというのはEclipseのSpring関係詰め合わせパックです。
要約すると、
- 1. Step in/Step outで、いままではreflection and cached call sitesのせいで本来不要なレベルのスタックフレームにはいっちゃってたのが、スキップできるようになった。
- 2. デバッグ中に任意のgroovy式を実行できるようになった。それだけでなく、エディタ中で選んだ式を評価できるようになった(CTRL-Shift-I )。
- 3. display viewでほとんどなんでも実行できるようになった。
- 4. MOPのもっとも奇妙なる利用
とのこと。詳しくは、参照先を見てください。図も多用されていてわかりやすいです。
読んだ限り、以下のようなことではないかと。
- 1は本来普通になされるべきことが修正された。
- 2、3については便利そうです。起動時間を考えると、「Grailsアプリ実行中に」Groovyコードスニペットが実行できるのは重要ですね*1。エディタで編集しながらコードが評価できるなら、オンザフライ、つまりアプリを止めずにテストコードを追加したりもできそうです*2。「テストの遅さ問題」をある程度低減できるかもしれません。また、「インクリメンタルに」コードを評価&追加していくことは、Groovyスクリプトを効率良く開発するために重要*3だと思っています。Emacsの「eval-last-sexp」の使用経験からの類推ですが。
- 4「MOPのもっとも奇妙なる利用」については、2、3でのコードの評価がどうおこなわれるか、という実装の話です。まず、デバッグ対象のGroovyアプリケーションが動作するJVM(Debugged JVM)の外側のJVM(Eclipseが動作しているJVM、Groovy Pluginが動作しているJVM)でGroovyコードスニペットをコンパイルしておいて、そこでのオペレーション(all method calls, property accesses, and constructor invocation)を、MOPでキャプチャしたうえで、コードを外側のJVMで実行し、キャプチャされたオペレーションを、JDI(Java Debugger Interface)を通じてDebugged JVM内に転送して、内側のJVM中で評価してやるそうです。戻り値もJDI経由で戻ってくるのでしょう。この方法によって、デバッグ対象アプリケーションに手を加えることなく、デバッグ対象JVMにスクリプトのクラスを追加したりロードさせたりすることもなく、任意のタイミングでコードを「外側から」評価実行できるということになります。おもしろいっすね!
Eclipseの利用は、業務開発では必須に近いと思うので、今回のような向上によって、Groovy/Graillsの本格適用可能性がさらに高まったといえるのではないでしょうか。
