garlic-decompiler と呼ばれる新しい Java デコンパイラが登場した。これは完全に C言語 で書かれており、従来の Java ベースのツールに比べて大幅な性能向上を主張している。このプロジェクトは、コンパイルされた Java バイトコードを読みやすいソースコードに変換することを目的とし、.classファイル、JARアーカイブ、WARファイルをサポートしている。
サポートされているファイル形式:
- .class ファイル（ Java バイトコード）
- .jar ファイル（ Java アーカイブ）
- .war ファイル（ Web アプリケーションアーカイブ）
- .dex ファイル（計画中、現在未サポート）
性能に関する主張と現実のチェック
開発者は garlic-decompiler が Java ベースの代替ツールより約10倍高速に動作し、システムリソースの使用量も少ないと主張している。コンパイルされたバイナリのサイズはわずか300KBで、非常に軽量である。しかし、コミュニティメンバーによる初期テストでは、複雑なデータ構造を扱う C プログラムに典型的な成長痛がいくつか明らかになっている。
あるユーザーは、マルチスレッドを有効にして JAR ファイルを処理中にセグメンテーション違反が発生したと報告し、Java バイトコード解析を処理する際の C言語 でのメモリ管理の課題を浮き彫りにした。開発者は迅速に対応し、問題を修正するために問題のあるファイルの提供を求めた。
パフォーマンス要求:
- Java ベースのデコンパイラより10倍高速
- Java の代替手段よりもリソース使用量が少ない
- マルチスレッド処理サポート（デフォルト：4スレッド）
メモリ管理の課題が表面化
コミュニティでの技術的な議論は、プロジェクトのメモリ管理アプローチに焦点を当てている。このデコンパイラはカスタム文字列ライブラリを使用し、マルチスレッド操作用に個別のメモリプールを実装し、シングルスレッドモード用にグローバルプールを使用している。
しかし、経験豊富な開発者たちは、コードが静的文字列とヒープ割り当て文字列を一貫性なく混在させている潜在的な問題を特定している。これにより、呼び出し関数が返されたメモリを解放すべきかどうかを適切に判断できない状況が生じ、メモリリークやクラッシュにつながる可能性がある。
開発アプローチと今後の計画
このプロジェクトは主に手動による取り組みを表しており、開発者は90%が手作業、10%が AI だったと述べている。これは、学習重視のプロジェクトにとって理想的な比率だとコミュニティの多くが考えている。動機は教育的かつ実用的なもので、より高速なツールを作成しながら JVM の内部構造を理解することを目的としているようだ。
「私は dex と apk をデコンパイルする部分を書いています。現在の速度は Java の約10倍で、Java よりもリソースの使用量が少なくなっています。」
今後の開発には Android DEX ファイルのサポートが計画されているが、この機能はまだ実装されていない。このプロジェクトには、より高速なバイトコード解析のための javap のようなモードも含まれており、性能向上のために LineNumber と StackMapTable 属性は無効化されている。
ビルド要件:
- cmake >= 3.26
- その他の依存関係なし
- コンパイル済みバイナリサイズ：約300KB
結論
garlic-decompiler は速度の主張と軽量設計で有望性を示しているが、複雑な解析タスクを処理する C プログラムの典型的な課題に直面している。バグレポートに対する開発者の積極的な対応とプロジェクトの教育的性質は、メモリ管理の問題が解決されれば、既存の Java デコンパイラの実用的な代替手段に成熟する可能性があることを示唆している。現時点では、複雑なバイトコード解析を扱う初期段階の C プロジェクトに典型的な粗い部分があることをユーザーは覚悟すべきである。