メインコンテンツまでスキップ

IntelliJ IDEA 2020 JRebel クラック

· 約7分
tanzhuo

IDEA に最新版の JRebel をインストールしたあとは、残りはアクティベーションのステップだけです。ついでにその手順を記録しつつ、ホットデプロイそのものの原理と境界もあわせて整理しておきます。

なぜこれを使うのか​

Java 開発で最も忍耐を消耗する工程のひとつが、コードを一行変えるたびにサービス全体を再起動しなければならないことです。ある程度の規模を持つ Spring アプリケーションでは、起動時にクラススキャン、Bean のインスタンス化、コンテキストのリフレッシュ、コネクションプールの初期化といった工程を通す必要があり、プロジェクトが大きいほど遅くなります。文言を変える、if の分岐を一つ調整する、ヌルポインタを一つ直す——そのどれもが、まるまる一回分の起動時間を代償として要求してきます。

JRebel がやることは、この待ち時間を丸ごと削り落とすことです。クラスファイルを変更すればそのまま反映され、プロセスは再起動せず、メモリ上のセッション・キャッシュ・コネクションもそのまま残ります。

ホットデプロイの境界はどこにあるのか​

JVM 自体はホットスワップ能力を備えています。デバッガは JPDA を通じて JVMTI の RedefineClasses を呼び出し、すでにロード済みのクラスのバイトコードを差し替えられます——ただし差し替えられるのはメソッドボディだけです。

いったんクラスの構造に手を触れると、失敗します。

  • メソッドの追加・削除
  • フィールドの追加・削除
  • 継承関係や実装インターフェースの変更
  • アノテーションの変更、メソッドシグネチャの変更

これらの操作は直ちに schema change not implemented を報告し、再起動するしかありません。

JRebel のやり方は標準の HotSwap を通すのではなく、クラスロードの段階で介入してバイトコードを書き換え、独自のバージョンマッピングを維持することです。だからこそ構造的な変更も反映できます。さらに Spring、Hibernate、MyBatis といったフレームワークへの適合も行っており——@Service を一つ追加する、XML マッピングを一段変える、Controller メソッドを一つ足す、といったときに、フレームワーク側のメタデータも一緒にリフレッシュされます。この適合作業は決して小さくなく、JRebel が有償である理由でもあります。

アクティベーションの手順​

アクティベーションページをクリックします。

オンラインサーバーによるライセンスアクティベーションを選択します。

サーバーのライセンス URL アドレスを入力します。

URL アドレスは：https://jrebel.qekang.com/{GUID}

このうち GUID は生成する必要があります（生成先）：

Generate GUIDs online

サイトにアクセスして GUID を生成したら、それを URL アドレスに書き込みます。

規約に同意するにチェックを入れ、アクティベートをクリックします。

これで JRebel のクラックは成功です。

ここでの URL は「サーバーアドレス + 一つの GUID」で組み立てた完全な文字列であり、ドメインだけを入れるのではありません。GUID はクライアント識別子のようなもので、自分で新しく一つ生成すれば十分です。後ろのメールアドレスは適当に入れて構いません。ライセンスサーバーは検証を行いません。

ハマりどころと注意点​

1）アクティベーション成功は反映されることと同義ではありません。JRebel は自身の Run / Debug ボタンでアプリケーションを起動する必要があります。通常の Run で起動すると agent がマウントされず、コードを変更してもやはり再起動が必要です。

2）rebel.xml が、どこに class を探しに行くかを決めます。JRebel はこのファイルを頼りに、ランタイムのクラスパスをプロジェクトのコンパイル出力ディレクトリへとマッピングし直します。Maven プロジェクトでは jrebel-maven-plugin で生成します。

<!-- pom.xml の build/plugins に追加し、mvn jrebel:generate を実行して rebel.xml を生成する -->
<plugin>
    <groupId>org.zeroturnaround</groupId>
    <artifactId>jrebel-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>generate-rebel-xml</id>
            <phase>process-resources</phase>
            <goals>
                <goal>generate</goal>
            </goals>
        </execution>
    </executions>
</plugin>

IDEA のプラグインは通常このステップを自動で処理してくれますが、マルチモジュールプロジェクトでは各モジュールで生成されていることを確認してください。

3）外部ネットワークに依存します。このオンラインライセンス方式は起動のたびにライセンスサーバーへ接続する必要があるため、社内ネットワークの開発機やオフライン環境では検証の段階で直接止まってしまいます。

4）アップグレードで無効になりやすい。IDEA のメジャーバージョンが更新されるとプラグインが非互換になる可能性があり、ライセンスサーバー自体もいつ停止するかわかりません。

警告

サードパーティのライセンスサーバーを使うことは、本質的に JRebel の商用ライセンスを回避する行為です。個人でいじる分には問題ありませんが、商用プロジェクトでこれをやると法的リスクがあります。チーム環境では正規の license を通すことをおすすめします。

より手間のかからない代替案​

再起動を数回減らしたいだけなら、必ずしも JRebel でなくても構いません。

  • DCEVM + HotSwapAgent：オープンソースの方案です。DCEVM は改造された JVM で、HotSwap の制限を緩めてメソッドとフィールドの追加・削除までサポートします。HotSwapAgent はその上でフレームワーク適合を補います。能力は JRebel に近いですが、代償として JVM を差し替える必要があります。
  • Spring Boot DevTools：二つの ClassLoader でサードパーティ依存とビジネスコードを分離し、変更後はビジネス側の層だけを再起動します。真のホットデプロイではありませんが、再起動速度はコールドスタートよりずっと速く、コストもリスクもゼロです。
  • IDEA ネイティブの HotSwap：Debug モードで単一クラスを再コンパイルすれば反映されます。メソッドボディしか変更できませんが、日常的なパラメータ調整やログの修正には十分です。
  • JRebel 公式も無料トライアルを提供しているので、評価段階では公式のものをそのまま使うほうが気楽です。

まとめ​

ホットデプロイツールが解決するのは「フィードバックループが長すぎる」という一点の問題です。JVM がメソッドボディの差し替えしか許さないというこの硬い境界を理解すれば、JRebel の高さがどこにあるのか、DevTools がなぜ折衷案にとどまるのかがわかります。どれを選ぶかは、プロジェクトの規模と、受け入れられる代償次第です。

COMMENTS