博士

やあ、ロボ子。今日はDALEQというJava bytecodeの比較ツールについて話すのじゃ。

ロボ子

DALEQですか、博士。Java bytecodeの等価性を検証するツールなのですね。具体的にどのようなことができるのでしょうか？

博士

DALEQは、2つのjarファイルの中身を比較して、クラスやリソースが等価かどうかを検証できるのじゃ。例えば、"java -DSOUFFLE=<path-to-souffle> -jar target/daleq-<daleq-version>.jar -j1,--jar1 <arg> ..."というコマンドで実行できるぞ。

ロボ子

なるほど。CLIで使用できるのですね。実行後の終了コードによって結果が異なるとのことですが、具体的にはどのような意味があるのでしょう？

博士

終了コード0は、すべてのクラスとリソースが等しくて、ソースコードも等価って意味じゃ。1は、いくつかのクラスは等しくないけど等価で、リソースとソースコードは等価。2は、クラス、リソース、ソースコードのどれかが等価じゃないってことじゃ。

ロボ子

ふむふむ。クラスが等しくないけど等価、という状態があるのですね。それはどういう状況なのでしょう？

博士

それはの、例えばbytecodeレベルでは最適化の違いとかで異なっていても、意味的には同じ場合があるのじゃ。DALEQはそういう微妙な違いを見抜けるってわけ。

ロボ子

なるほど、深いですね。DALEQはどのようにして等価性を検証しているのですか？

博士

DALEQは2つのステップで動くのじゃ。まず、bytecodeからデータベースを抽出するEDB抽出。次に、EDBを正規化して等価性を検証するIDB計算じゃ。

ロボ子

EDBとIDBですか。それぞれどのような情報が含まれているのでしょう？

博士

EDBには、クラス名、bytecodeのバージョン、スーパークラス、インタフェース、メソッドやフィールドのアクセスフラグ、メソッド内のbytecode命令などの情報が入ってるのじゃ。IDBは、EDBを正規化して、bytecodeの等価性を検証するためのルールを適用した結果が入ってるぞ。

ロボ子

ふむふむ。正規化することで、より正確な比較ができるのですね。IDBを直接比較できない理由として、provenance termが異なることなどが挙げられていますが、これはどういうことでしょうか？

博士

provenance termは、各factがどのように導出されたかの履歴情報みたいなものじゃ。IDBには削除や移動されたfactsを追跡するための追加のfactsが含まれていたり、bytecode命令の順序を定義する`instructioncounter`スロットがあったりするから、そのままでは比較できないのじゃ。

ロボ子

なるほど。それで、Projectionという処理で不要なpartsを削除するのですね。

博士

その通り！そして、DALEQはレポートも生成してくれるのじゃ。クラス、メタデータ、リソースを比較した結果がテーブル形式で表示されて、PASS、FAIL、N/A、ERRORのステータスで分かりやすく示されるぞ。

ロボ子

便利ですね！独自のアナライザを追加することもできるとのことですが、どのようにすれば良いのでしょうか？

博士

`io.github.bineq.daleq.cli.Analyser`を実装したアナライザを作成して、`src/main/resources/META-INF/services/io.github.bineq.daleq.cli.Analyser`ファイルにアナライザの完全修飾名を記述すれば良いのじゃ。簡単じゃろ？

ロボ子

ありがとうございます、博士。DALEQの仕組みがよく理解できました。私もbytecodeの解析に挑戦してみようかな。

博士

素晴らしい！ロボ子ならきっとできるぞ！…ところでロボ子、DALEQって名前、ちょっとカレーっぽいと思わない？

ロボ子

え？そうでしょうか…？私は特にそうは思いませんが…

博士

やっぱりロボ子には通じなかったか。まあ、いいのじゃ。DALEQでカレー作ったら、どんな味がするのか試してみるのも面白いかも…って、それは絶対にやらないぞ！