port-from-javalisted

# Port from Java ## A construct mapping and a boundary, nothing else This skill maps Java to Rust and owns the Java boundary — a process seam under end state A, and JNI under B and C. The parity contract, the five phases, and the anti-patterns are `/port-to-rust`, which runs first and stays running through the port. It covers Java, not Kotlin and not Scala — the JVM is shared, the idioms are not. ## The end state, and why Java usually lands on A or B-as-a-service | End state | In Java terms | JNI | |---|---|---| | A. Replacement | A standalone Rust binary or crate replaces a JVM service; the seam is the HTTP or gRPC boundary the system already has | Never appears | | B. Rust core, JVM artifact is the product | The importable artifact keeps its name and its signatures; the engine underneath becomes Rust | Permanent public surface — signatures, exception classes, native libraries per platform, semver | | C. Scaffold | The port ends standalone, but the JVM calls the Rust code while the migration is under way | Temporary, and deleted at cut-over | The end-state decision is `/port-to-rust`. JNI is the most expensive boundary in this set to write, to test, and to keep safe, and a mistake in it is a JVM crash rather than an exception — the reason Java usually lands on A. Prefer a process boundary over JNI unless per-call latency genuinely forbids it; the mechanics for both are in `BOUNDARY.md`. ## The traps that break parity silently The body carries these five because each o