一個名為 garlic-decompiler 的新 Java 反編譯器已經出現，完全用 C 語言編寫，聲稱相比傳統的基於 Java 的工具有顯著的效能提升。該專案旨在將編譯後的 Java 位元組碼轉換回可讀的原始碼，支援 .class 檔案、JAR 歸檔檔案和 WAR 檔案。
支援的檔案型別：
- .class 檔案（Java 位元組碼）
- .jar 檔案（Java 歸檔檔案）
- .war 檔案（Web 應用程式歸檔檔案）
- .dex 檔案（計劃支援，目前暫不支援）
效能宣告與現實檢驗
開發者聲稱 garlic-decompiler 的執行速度比基於 Java 的替代工具快約 10 倍，同時使用更少的系統資源。編譯後的二進位制檔案僅重 300KB，使其極其輕量。然而，社群成員的早期測試揭示了一些成長期的問題，這在處理複雜資料結構的 C 程式中很典型。
一位使用者報告了在啟用多執行緒處理 JAR 檔案時出現段錯誤的問題，突顯了 C 語言在處理 Java 位元組碼解析時記憶體管理的挑戰。開發者迅速回應，請求提供有問題的檔案以修復該問題。
效能宣告：
- 比基於 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 專案典型的粗糙邊緣。