[rustjava-lock-every-named-exception-class-is-loadable] test(ci): 이름으로 부르는 예외 클래스가 실을 수 있는 것인지 한 자리에서 대조한다 [rustjava-lock-every-named-exception-class-is-loadable-fix]

[Jun025]

Jvm::exception ends in new_class(...).await.unwrap() (jvm/src/jvm.rs:943-950), so naming a class the bootstrap loader cannot resolve panics instead of throwing. The axis is self-referential: jvm.rs:842 reports a missing class by calling exception("java/lang/NoClassDefFoundError", ...).

Adds one cross-check — scripts/check-named-exception-classes-are-loadable.py — comparing the literal class names in exception( call sites against the protos actually registered in rustjava-runtime/src/loader.rs. Wired into the DoD block and a CI job (named_exception_classes).

Baseline measured this round: 41 distinct literal names / 812 call sites ↔ 265 registered entries (263 distinct), all resolved ⇒ 0 not loadable.

Bidirectional: removing the BootstrapMethodError registration — the case that actually panicked — gives rc=1 naming it at jvm-bytecode/src/interpreter.rs:1109; renaming a proto gives rc=1; an unresolvable registration gives rc=2 (cannot measure) rather than a false red; restoring gives rc=0.

It is a floor, not a proof: a name built at run time (format!, a const, a variable) is invisible. The .unwrap() itself is deliberately untouched — that conversion is a separate axis.

No runtime class added. Cost ~1s (the first draft took 32.7s until target/ was pruned).

Adopted proposal: 2026-09-17-string-concat-recipe-arity#p0