SlimeNENC family · structural translation · Isolation Method PoC

SlimeJava — Bit-Exact Java → Rust Isolate Model

The same structural-translation engine that converts legacy COBOL / JCL / MUMPS / PL/I / RPG to Java & Rust now covers Java. Java source becomes Rust source, and the two produce byte-for-byte identical output (SHA-256) on the same input. Not “approximately equivalent”. Byte-for-byte.

LANGUAGE · SlimeNENC

We don’t understand the meaning. We project the structure into Rust.

We do not “understand the meaning” of your Java and rewrite it. Meaning depends on human perception — there is no mathematical rigor in it. The source is structure. SlimeJava projects (π) that structure onto Slot IR and transcribes it, structure-preserving, into Rust. Java’s two’s-complement wrapping, shift masking, and divide-by-zero exception are reproduced in Rust down to the last bit. No probabilistic code generation, no LLM in the path — deterministic, bit-exact, third-party reproducible.

Modern sibling: SlimePython → Request a PoC →

An honest promise. SlimeJava does not promise perfect bit-exactness for all Java code. The statically projectable core (integers, control flow, bit operations) is strongly guaranteed bit-exact; the dynamic, state-dependent region is split into an isolate and made bit-exact as it settles (tier-2 Lisp-JIT). We value “you can actually use it and prove behavior is unchanged” over “100% in theory.”

Java 8 / 17 / 21→ Rust 1.75+SHA-256 bit-exactinteger traps reproducedexception path bit-exactSlot IRno LLM in path~57,000 fuzz cases, 0 divergence2,900 corner cases byte-identicalreal OpenJDK: 23 methods, 603 casescold start ~41× vs JVMSMT: formal proof over all inputsarray OOB bit-exactRSS ~22× smallerconversion certificate + CI gatefull Java accepted (Hybrid 99%)

What it does

SlimeJava takes a statically analyzable Java subset (int/long arithmetic, control flow, bit operations, arrays, exception paths) and emits a Rust (Cargo) project. The contract is strict — on the same input, the original Java and the generated Rust produce byte-identical output. Every conversion ships with a Java/Rust comparison harness, so any third party can re-run the proof with sha256sum.

We don’t “understand.” That’s why it’s bit-exact.

The crux is to deliberately discard the “understand the meaning” step. “Meaning” depends on human perception and varies — so an “understand and rewrite” migration imports that variance. SlimeJava treats the source as structure (unambiguous, unique), projects it onto Slot IR, and transcribes it into Rust structure-preserving. Because it never passes through the meaning layer, the result is mathematically rigorous — Java’s two’s-complement wrapping, shift masking, and divide-by-zero exception are reproduced down to the last bit.

Absolute rule (isolate, don’t confabulate). We never emit “approximately equivalent” output. Syntax outside the static subset is sent to the isolate, not silently translated. Rather than guess a translation, it declines to translate.

Full Java — Hybrid Bit-Exact Isolate

“Full Java” does not mean rewriting everything into Rust (objects/String/double/reflection cannot be made bit-exact in Rust). It means accepting all Java. Any Java is auto-partitioned into three regions, each given the strongest honest guarantee:

Region	Target	Guarantee
Static core (integer/control/array/bit)	→ pure Rust	100% bit-exact (+ SMT proof over all inputs)
Dynamic (object/String/double/reflection)	→ Java, on a deterministic JVM Isolate	fixed-JVM 95-99%
True nondeterminism (unseeded random/wall-clock/I/O/concurrency)	→ reject	bit-exact not guaranteed (explicit)

Measured Hybrid acceptance is 98.7–100% (breaking past the static-only 37% wall). An auto-partitioner Hybridizes mixed Java in one command and verifies byte-identity against the original.

An honest split. 99% acceptance means “handles all Java,” but ≠ “all rewritten to Rust.” Only the static core is peeled into bit-exact Rust and gets the lightness/predictability benefit; the rest runs on the deterministic JVM Isolate (95-99%), and true nondeterminism is rejected. We never claim “always 100% across the whole Hybrid.”

Evidence — all third-party reproducible

Every claim is backed by real compilation & byte-diff / SMT proof over all inputs:

No-holes proof~60,000-case differential fuzzing (random + exhaustive corner cases) byte-identical to Java, zero divergence. 603 real OpenJDK cases (23 methods) also match.
Formal (SMT)bitCount (32/64-bit) equals popcount, etc. — 12 methods + division machine-proven over all inputs (0 counterexamples).
PerformanceThroughput on par; startup ~41×, RSS ~22× smaller, p99 tail flat (no GC). The value is “light, predictable, bit-exact.”
Hybrid330 programs auto-Hybridized, 2,259 boundary calls — byte-identical through the exception boundary.

The measurement procedure, full verification data, and reproduction commands are consolidated on the resource page (measurement procedure & primary data).

The three-tier model — the SlimeNENC desk

Tier	Computation	Guarantee
① Static projection (SlimeJava)	reproducible integer / logic	byte-identical
② Lisp-JIT	reproducible once it settles at run time	byte-identical (after settling)
③ Semantic judge	non-reproducible (float / parallel / AI)	meaning-equivalence + convergence + residual

Where there is form, prove it in bytes; where there is none, in meaning. Lie on neither face — that is the SlimeNENC desk.

Using it as a product — certificate + CI gate

One command does convert → run → byte-diff → issue certificate. The exit code drops into a CI gate that goes red if behavior changes by a single bit. The certificate records input SHA-256, converted methods, output hashes, and verdict, re-runnable by a third party. Human “close enough” UAT is replaced by a machine-checkable “certificate of behavioral invariance.”

Tier	Contents	Guarantee
Free / Open	converter + differential verifier + certificate CLI	byte-diff 0 (practical)
Pro	+ SMT all-input formal proof + CI integration + audit trail	all-input machine proof + diff

Pricing / SLA are quoted per use case and scale — contact us. Ideal as the “peel the integer core from Java to Rust” phase extending a COBOL / PL/I legacy migration.

Status

SlimeJava is at the Isolation-Method PoC stage, with everything above demonstrated. It is a member of the SlimeNENC structural-translation family — legacy side: COBOL / JCL / MUMPS / PL/I / RPG & assembler; modern side: Python. Full verification data is on the resource page. For pricing and contracts, contact us.

Contact / request a PoC Measurement procedure & full data SlimePython Other products