[rustjava-classfile-parse-error-propagation] fix: unreadable class files raise ClassFormatError instead of panicking

[Jun025]

What

ClassDefinitionImpl::from_classfile — the single definition path every user class from the classpath/jar goes through — called ClassInfo::parse(data).unwrap() plus assert_eq!(magic). Any corrupted class file, or any class containing constant pool tags 15–18 (MethodHandle/MethodType/Dynamic/InvokeDynamic — which javac 9+ emits by default for string concatenation and lambdas), killed the entire process with a Rust panic. Since there is no catch_unwind anywhere, an embedding host dies too. Meanwhile "class not found" was already a clean java.lang.NoClassDefFoundError — only "class unreadable" panicked.

Changes

• classfile: ClassInfo::parse returns Result<Self, ParseError> instead of Option. ParseError distinguishes: Truncated, BadMagic(u32), UnsupportedConstantPoolTag { index, tag }, Malformed, TrailingData. parse_utf8 no longer panics on invalid UTF-8. Internal nom parsers untouched otherwise.
• jvm_rust: from_classfile returns Result<Self, ParseError>; unwrap()/assert_eq! removed.
• java_runtime: new java/lang/ClassFormatError runtime class (extends LinkageError, mirrors NoClassDefFoundError's structure), registered in the class list.
• RuntimeImpl / TestRuntime define_class: on parse failure, raise jvm.exception("java/lang/ClassFormatError", <cause>) — the exact convention NoClassDefFoundError already uses (jvm.rs:579). No new mechanism.

ClassFormatError (not UnsupportedClassVersionError) is used for unsupported tags: per JVMS and HotSpot behavior, unknown constant tags produce ClassFormatError: Unknown constant tag N; UnsupportedClassVersionError is reserved for major/minor version mismatch, which is not what happens here.

Evidence

Before fix (tests added first — both audit repro cases reproduce through the binary path):

thread 'test_truncated_class_raises_class_format_error' panicked at jvm_rust/src/class_definition.rs:100:44:
called `Option::unwrap()` on a `None` value

(same for tag-18 mutation and bad magic; not-found control already passed)

After fix, the deployed binary:

$ rust_java Truncated
Error: Java Exception:
java.lang.ClassFormatError: Truncated class file
	at java/net/URLClassLoader.defineClass...

$ rust_java BadTag        # first CP tag byte mutated 10 -> 18
Error: Java Exception:
java.lang.ClassFormatError: Unknown or unsupported constant pool tag 18 at index 1 in class file

$ rust_java NoSuchClass   # unchanged control
Error: Java Exception:
java.lang.NoClassDefFoundError: NoSuchClass

• tests/test_class_format.rs: 4 tests (truncated / tag 18 / bad magic / not-found control), fixtures derived deterministically from committed test_data/Hello.class by byte manipulation at test time — no corrupted binaries committed.
• cargo test --all fully green (129 tests, 0 failures), cargo fmt --check and cargo clippy --all-targets clean.

Merge note

This PR and #2 both add STATE.md/REPORT.md (SOP files, new on main). Whichever merges second will show an add/add conflict — resolve by merging main into the remaining branch and taking this branch's superset versions.

Non-goals (per ticket)

• Actual invokedynamic/MethodHandle/lambda support — unsupported tags are cleanly rejected, not implemented.
• Constant pool cross-reference validation (.get().unwrap() on dangling indices) — separate corruption class, out of scope.
• No upstream (dlunch/RustJava) contact.

🤖 Generated with Claude Code