The gist: SlimeJava makes its "behavior-invariance certificate" JDK-version-aware. SlimePython deterministically lifts dynamic syntax too.
We've advanced the modern-language side of the SlimeNENC family — SlimeJava and SlimePython. Both keep the same design ("don't understand meaning; project structure into Rust") while making bit-exactness (1-bit-identical output for the same input) even more honest.
SlimeJava — the certificate now knows the JDK version
When you claim byte-identical output, there's an easily overlooked trap: exception message text varies by JDK version. An array out-of-bounds is 9 (just the index) on JDK 8, but Index 9 out of bounds for length 3 on JDK 11+. Helpful NullPointerException messages arrived in JDK 14/15, and StringIndexOutOfBounds changed again in JDK 21.
Hard-coding "JDK 21 wording" means the bytes diverge the moment you run on JDK 8. SlimeJava now reproduces each wording per JDK version and stamps the target JDK major (8 / 17 / 21) into the certificate. On real OpenJDK 8 / 17 / 21, byte-identical output matching each JDK's wording is confirmed.
"byte-diff 0" is no longer an unconditional claim — it's an honest, version-scoped guarantee.
SlimePython — lift dynamic syntax, never silently translate
Python's dynamism (getattr, attribute hooks, function replacement) drifts if translated naively to Rust. SlimePython conditionally static-lifts only the dynamic patterns that can be made bit-exact, and explicitly rejects the rest rather than translating them silently.
Extended this round:
- Attribute dispatch — finite-enumerable
getattr(==chains /in (...)tuples), incl.self- and__init__-dependent returns, lifted as per-key methods - Function replacement — rebinding functions that take arguments; blessed patches swapping
time/random/uuidfor deterministic versions - Soundness — type conflicts that can't fit one Rust type (e.g. int and str mixed across call sites) are statically detected and rejected; wrappers that observe the (non-deterministic) original are rejected too
Everything is verified with a three-way SHA-256 match: Python = native Rust = WASI Rust.
Why "rejecting" is a feature
If you chase bit-exactness seriously, "honestly not translating what you can't" becomes the quality itself. Instead of emitting code that's "probably close," we make explicit the range we can prove 1-bit-identical, and surface the rest as a boundary. It's the SlimeNENC family's shared stance: make the desk honest.
For detailed verification data, see the product pages (SlimeJava / SlimePython) and the resource / PoC deep-dive.