[rustjava-adopt-classfile-error-cause-decision-p0] fix(classfile): 거부 사유를 세 층에 꿴다 — validate_class 를 규칙마다 쪼갠다 [rustjava-adopt-classfile-error-cause-decision-p0-fix] [rustjava-adopt-classfile-error-cause-decision-p0-fix2] [rustjava-adopt-classfile-error-cause-decision-p0-conflict-resolve]

[Jun025]

채택 제안 2026-09-17-classfile-error-cause-decision#p0. 제품 동작 변경 있음 —
ClassFormatError 메시지가 모든 거부에 같던 「Invalid class file」 에서 사유별 문장이 된다.

제안이 스스로 all-or-nothing 이라 못박았다(타입만 고치면 관측되는 것이 없고, || 사슬을 안 쪼개면
평평함이 사라지는 게 아니라 옮겨갈 뿐). 넷 다 했다:

ClassFileError::InvalidFormat(&'static str)
 → ClassDefinitionError::InvalidClassFile(&'static str)   ← From 이 «버리던» 자리
    → jvm.exception("java/lang/ClassFormatError", cause)  ← 두 자리 모두

＋ validate_class 의 8항 || 사슬 → 규칙마다 if 하나(사유 13개).

사유를 꿰자마자 «평평한 오류가 가리던 것 둘»이 나왔다

1. 테스트가 어느 층이 거부하는지를 틀리게 믿었다 — 「인덱스가 엉뚱한 종류를 가리킨다」는
   검증이 아니라 파서가 거부한다. ★코드를 추측에 맞추지 않고 단언을 실측에 맞췄다.
2. 술어 이름이 낡아 있었다 — ..._are_in_the_pool 은 이름과 달리 「적재 가능 상수인가」까지 본다
   (직전 회차가 넓혔다). 사유는 규칙대로 적고 ★이름은 바꾸지 않았다(리팩터 = 범위 밖).

양방향 — 세 층 전부에 개악

M1 경계가 다시 문자열을 박는다 → red · M2 From 이 사유를 버린다(제안이 지목한 그 버그) → red ·
M3 두 사유를 한 문자열로 접는다 → red(dedup 단언이 잡는다 — 이게 없으면 전부 되돌려도 통과) ·
복원 17/0.

대가 (실측한 구멍 포함)

• ★마지막 홉이 두 번 쓰여 있고 test-utils 사본은 무검증: 그 사본만 개악해도
  cargo test --all 이 579 passed / 0 failed. 합치는 것은 리팩터라 하지 않고 보고한다.
• 사유가 문자열이라 두 규칙에 같은 문구를 주는 것을 막는 것이 없다.
• 픽스처 규율을 대체하지 않는다(제안이 이미 적었다).
• ★**[rustjava-adopt-reject-duplicate-bootstrap-methods-p0] fix(classfile): 단일값 클래스 속성의 「개수 규칙」 — 진짜 JVM 이 거부하는 다섯에만 #66 과 같은 함수를 만진다** — 뒤에 착지하는 쪽이 base 를 당겨 그 항을 다시 쪼갠다(기계적).

cargo test --all 578 → 579 / 0 failed / 1 ignored · DoD 7명령 rc=0.