JavaJive — Pure-Go Java Toolkit: Decompile, Class Parse, Serialization

JavaJive

Ein portables, reines Go-Java-Toolkit — extrahiert und verschlankt aus yaklang — das drei Dinge tut und sonst nichts:

Dekompilieren — .class / .jar / .war / .zip → lesbarer Java-Quellcode.
Klassen parsen — die Struktur einer .class-Datei inspizieren (Konstantenpool, Felder, Methoden, Version, Zugriffsflags).
(De)serialisieren — das Java-Serialisierungs-(ObjectStream-)Wire-Format mit Byte-Treue parsen und neu marshallen sowie nach/von JSON konvertieren.

Gebaut für Portabilität und Einbettung:

Reines Go, einzelne Binary — kein JDK, kein cgo, keine ANTLR-Runtime, keine nativen Bibliotheken. Cross-Compiles für linux / macOS / windows auf amd64 und arm64.
Ein Import — ein einheitliches javajive-Facade-Paket umschließt alle drei Fähigkeiten; die Unterpakete bleiben für fortgeschrittene Nutzung verfügbar.
Erstklassige CLI — decompile-, classinfo- und serial-Unterbefehle, auf Basis der Standardbibliothek.
Kreuzgetestet gegen ein echtes JDK — CI kompiliert echte .class / .jar und JDK-serialisierte Blobs mit javac/java und verifiziert JavaJive dagegen (siehe HARNESS-WORKFLOW.md).
Verschlankter Abhängigkeitsgraph — utils / codec / log / go-funk sind als minimaler, eigenständiger internal/-Kern neu implementiert.

Validierung von v0.4.0

Der vollständige 38-JAR-Differenz-Audit verzeichnet null dokumentierte Regressionen gegen die feste Baseline: alle 20 zuvor kompilier-sauberen JARs bleiben erhalten und 26 kompilieren nun vollständig. Baseline-Defekte und 4 bestehende Methoden-Stubs bleiben sichtbar. Siehe die Ergebnisse pro JAR und Reproduktion.

250 isolierte semantische Round Trips erfassen Kompilierung, JVM-Verifikation, Stubs und Laufzeitgleichheit getrennt; ursprüngliche Anwendungsklassen fehlen in neu gebauten Classpaths. CI führt den semantischen Audit auf JDK 17 und 21, den vollständigen historischen Vergleich sowie die OS/Go- und Race-Matrizen aus. Diese Prüfungen beweisen nicht die Äquivalenz jeder Bibliotheks- methode. Siehe die Implementierung und verbleibende Grenzen.

Historische Benchmarks (v0.3.0)

Die folgenden Zahlen wurden für v0.3.0 am 2026-09-05 berichtet. Sie sind keine Akzeptanzergebnisse der aktuellen Version und kein Beweis für Verhaltensäquivalenz.

Gemessen an 34 realen Jars (18.759 abgeflachte Einheiten) via decompile → javac --release 8 Recompile → Repackage → JVM-Verify:

100 % Unit-Clean-Rate — 18.759 / 18.759 abgeflachte Einheiten (Outer$Inner.java) kompilieren mit null javac-Fehlern neu, und 0 Syntaxfehler über alle 34 Jars (eine CI-erzwungene harte Assertion, sodass kein Typfehler sich hinter einem Lexer-Fehler verstecken kann).
Alle 34 Bibliotheken vollständig round-trip — decompile → recompile → repackage → externe JVM -Xverify:all-Verifikation pro Klasse läuft Ende-zu-Ende durch (Codec ist byte-identisch zum Original-Jar unter einem Call-Differential). In provenClean festgeschrieben.
14 / 14 selbst gehostete Algorithmen (MD5 · SHA-256 · CRC32 · Quicksort · Base64 · HeapSort · KMP · SwitchFSM · TryFinally · UnionFind · DiamondTryCatch · DiamondTryFinally · ForContinue · ComputeIfAbsent) round-trip byte-für-byte.
#1 in einem fairen 3-Wege-Vergleich auf dem ursprünglichen 8-Jar-Set — Clean-Unit-Rate 100 % vs Vineflower 1.10.1 (90,8 %) und CFR 0.152 (79,8 %); gewinnt alle 8 Jars gegen beide.

Siehe BENCHMARK.md für die vollständige Methodik, Tabellen pro Jar und Reproduktionsbefehle.

Installation

# CLI
go install github.com/yaklang/javajive/cmd/javajive@latest

# Library
go get github.com/yaklang/javajive@latest

Oder aus dem Quellcode bauen:

git clone https://github.com/yaklang/javajive
cd javajive
go build -o javajive ./cmd/javajive

Erfordert Go 1.22+.

CLI

javajive <command> [arguments]

Commands:
  decompile   decompile .class/.jar/.war/.zip or a directory into Java source
  classinfo   print the structure of a .class file (version, fields, methods)
  serial      Java serialization tools (subcommands: tojson, fromjson)
  version     print the version
  help        show help

decompile

# Single class: prints to stdout by default, or -o to write a file.
javajive decompile Foo.class
javajive decompile Foo.class -o Foo.java

# Archive: defaults to a "<input>.src" directory, or -o to choose one.
javajive decompile app.jar
javajive decompile app.war -o ./app-src

# Directory: recursively decompile .class files (requires -o output dir).
javajive decompile ./classes -o ./src

classinfo

javajive classinfo Foo.class

class:      InvisibleAnnoSeed
super:      java/lang/Object
version:    61.0
access:     public
constants:  18

fields (0):

methods (2):
   <init>()V
   run()I

serial

# Serialized binary -> JSON. (-hex: input is a hex string, -: read from stdin)
javajive serial tojson dump.bin
printf 'aced000574000568656c6c6f' | javajive serial tojson -hex -

# JSON -> serialized binary. (default prints hex; with -o writes raw bytes)
javajive serial fromjson dump.json -o out.bin
javajive serial fromjson dump.json          # prints hex

Bibliothek

Verwende das einheitliche Facade-Paket — ein Import deckt alle drei Fähigkeiten ab:

import "github.com/yaklang/javajive"

// Decompile a single class, or a whole archive into a directory.
src, err := javajive.Decompile(classBytes)
err = javajive.DecompileArchive("app.jar", "app-src")

// Inspect class structure.
obj, err := javajive.ParseClass(classBytes)
_ = obj.GetClassName()

// Java serialization: binary -> JSON -> binary.
objs, _ := javajive.ParseSerialized(raw)          // or ParseSerializedHex(hexStr)
jsonBytes, _ := javajive.SerializedToJSON(objs...)
restored, _ := javajive.SerializedFromJSON(jsonBytes)
out := javajive.MarshalSerialized(restored...)

javajive

Beliebteste