[mahaloz]

kuna could only decompile native binaries. This adds a second engine for the JVM: point the same commands at a .class file, a jar or a class directory and get Java back, or Kotlin for Kotlin classes.

$ kuna decompile tests/fixtures/jvm/app.jar com.ex.util.Helper.loop

Before:

error: could not build an architecture for tests/fixtures/jvm/app.jar: unrecognized input format; ...

After:

public static int loop(int n) {
   int total = 0;

   while (n > 0) {
      if (n % 3 == 0) {
         total += n;
      } else {
         total--;
      }

      n--;
   }

   return total;
}

What it is

• decompiler/nonnative/kuna-jvm is a Rust port of Vineflower 1.12.0 (Apache-2.0, credited in NOTICE) with its Kotlin, IDEA-not-null and variable-renaming plugins. It keeps Vineflower's Java-level IR and does not lower bytecode to p-code: class files carry types, exception tables and structure that p-code would discard and the native passes would have to guess back. It shares the CLI, the option catalog, the output shapes and the phase-folder layout with the native engine, and no code with kuna-decomp.
• With --option jvm_vineflower_compat on the output is byte-identical to Vineflower's for the same input, options and JDK, which makes Vineflower's own test suite the regression oracle. By default kuna also fixes Vineflower bugs (below).
• decompile, decompile-all, decompile-project, functions, catalog --engine jvm, test --jvm and docs jvm accept JVM inputs. The engine is picked from the file's magic; flags that only make sense for native images exit 2. The 74 engine options are jvm_* rows in the same catalog (docs/options-jvm.md).
• Native decompilation is unchanged: no datatest or stage assertion moved, a whole-binary export of /usr/bin/gzip is byte-identical, each invocation costs about 1 ms more, and the binary grows from 38.4 to 50.1 MB.

Compared with Vineflower

All 110,238 methods of five projects, scored against the original source on control flow, types and recompiled bytecode. In compat mode every score is identical to Vineflower's; the times below are from that mode, both tools back to back on one machine, Vineflower with 12 threads. docs/jvm-benchmark.md has the commands to rerun it (scripts/javabench).

Project	Methods	Perfect on every metric (compat)	kuna wall / peak memory	Vineflower wall / peak memory
guava	12,167	91.86%	2.1 s / 1.5 GiB	4.5 s / 3.8 GiB
spring-boot	3,967	88.98%	0.7 s / 0.7 GiB	2.7 s / 1.6 GiB
spring-framework	13,874	90.83%	3.2 s / 1.5 GiB	6.0 s / 4.7 GiB
ghidra	18,153	80.05%	3.4 s / 1.4 GiB	7.1 s / 6.9 GiB
elasticsearch	62,077	84.20%	17.7 s / 7.4 GiB	29.2 s / 11.5 GiB

On a single thread kuna is still 1.2 to 2.2 times slower than Vineflower.

Where kuna departs from Vineflower

kuna fixes 238 Vineflower 1.12.0 bugs in its own engine, 131 of them in Kotlin output. They are always on and have no options; --option jvm_vineflower_compat on turns them all off. Each has a case in tests/jvm/kuna-fixes/ checked in both modes, and docs/jvm.md lists them.

• 26 decompile methods or classes Vineflower fails on: irreducible loops holding a try, pattern switches, Kotlin references, default-argument constructors and suspend functions, a finally kotlinc split around a suspension point, exception ranges kotlinc 1.3 made overlap without nesting, ...
• 202 correct code Vineflower prints wrong or javac or kotlinc rejects. In Java: (long) a * b printed as an int product that overflows, a cast that makes javac call the method itself (Guava's Joiner.appendTo), a finally run once per loop iteration, unboxing dropped so that boxes are compared by identity, raw generic constructors, assert as an expression, the casts and type arguments generic inference needs, Arrays.asList(new T[n]) printed as Arrays.asList(), build(new String[0]) printed as a call to itself, casts dropped so that another overload is called, doubles printed as float literals, Objects.requireNonNull(x); deleted, o.super(..) printed as super(..), a write in a finally lost to the code after the try, a synchronized body run outside its lock or under a re-read lock, hand-written code turned into try-with-resources, ... In Kotlin: suspend functions printed as kotlinc's state machine (continuation class, label dispatch, spilled locals) rather than their body, raw generic types, which Kotlin does not have, data classes whose properties are declared in the body, inner classes constructed through the outer class's name, kotlinc 1.3's parameter checks on inline lambda parameters, Byte and Char values used as Int without the conversion Kotlin requires, default values printed as = ... or as another function's, when over an enum through kotlinc's $WhenMappings arrays, the objects kotlinc copies out of inline functions printed as separate $$inlined classes, @Volatile and @Transient dropped from properties, enum constants that lost their arguments, extension properties declared without their receiver, accessors that call themselves instead of reading field, $ in strings read as a template, property initializers and companion constants lost, @Synchronized accessors that lost the flag, !! dropped, nullable values cast as non-null, an extension property assignment that assigned the receiver, calls through facade classes Kotlin cannot name, operators parenthesised by Java's precedence (x or 1 shl k means (x or 1) shl k), != for identity tests, Char and Byte arithmetic typed as in Java, line breaks that end a statement early, parameters named new or default read through undeclared variables, field reads and calls inlined past code that changes their result, $ names and keywords without backticks, dropped returns, wrong for loop bounds, $default bridge calls, constructors printed as functions, abstract functions with bodies, Java member names (.length(), charAt), classes without Kotlin metadata written in Java syntax, ...
• 8 rebuild what the bytecode shows: try-with-resources whose resource class is outside the input or whose javac 11+ class file targets Java 8, compound assignments (no longer writing x = e + x as x += e either), new Inner() instead of Outer.this.new Inner(), switch cases in source order without javac's table fillers and synthetic default, and a test and cast where javac's bytecode shows no pattern. 2 make failure comments name their cause.

Three options, on by default and off under jvm_vineflower_compat on, write equivalent code in the form the class file shows the source had: jvm_javac_layout lays out ifs, loops and exits as javac laid out the bytecode (two returns stay two returns rather than return c ? a : b, ifs keep the source's polarity, early return;, continue; and break; stay, also inside loops and try, code javac placed after a loop stays after it, while and for as the source wrote them, false == x stays), for classes without Kotlin metadata; jvm_source_locals keeps the locals the class file names instead of folding them into their use, declares them in slot order and in the source's scopes, and keeps ++ and -- statements the source wrote as statements; jvm_source_patterns keeps a test and a cast the line table shows the source wrote, rather than an instanceof pattern.

On the benchmark, default mode raises the methods perfect on every metric from 94,106 to 109,007 (85.37% to 98.88%; every project above 98.7%), recovers all 17 methods Vineflower fails or prints unparseable, and makes 380 more classes recompile (7,988 of 8,155), losing none. 15,365 methods score better; 32 score worse on at least one metric (docs/jvm-benchmark.md lists them with the cause). On Kotlin libraries the methods left as failure comments drop from 38 to 0 in kotlin-stdlib, from 2 to 0 in okio, from 3 to 0 in okhttp and from 71 to 0 in kotlinx-coroutines (decompiled as Java with jvm_plugins 0, no method fails either, where Vineflower fails 24), and calls through $default bridges from 446 to 20 over okio, okhttp, kotlin-stdlib and kotlinx-coroutines. Compiled whole with kotlinc 2.0, the decompiled okio has 96 errors instead of 6,185, okhttp 441 instead of 9,988 and kotlinx-coroutines 6,876 instead of 18,722 (31 of 50, 63 of 131 and 110 of 396 files compile, instead of 2 of 50, 3 of 148 and 43 of 506).

Robustness: recursion too deep for the stack fails that one method or class with a StackOverflowError instead of ending the run, and the per-method time limit counts work rather than wall time, so the same methods stop on every run at any worker count.

Tests

• make test-jvm runs 1,151 cases: 607 byte-identical to Vineflower's output in compat mode (530 Java cases from Vineflower's suite, 6 for the two small plugins, 71 Kotlin), and the 272 fix and option cases in both modes. No JDK is needed, and decompiler/nonnative/kuna-jvm/tools/oracle regenerates the expectations from Vineflower.
• 724 engine tests, most of them replaying vectors produced by Vineflower's own classes, plus 44 CLI tests and tests/cli probes for the new surface.
• Whole jars in compat mode: the five benchmark jars, okio and okhttp come out identical, apart from the stack-trace text in the comment written when Vineflower itself fails a method.

Not covered yet on JVM inputs: strings, xrefs, disassemble and the call-graph options.

🤖 Generated with Claude Code

https://claude.ai/code/session_013BBaWRszChd3Ho4R3P4cA4