[rustjava-unsupported-charset-exception] Throw UnsupportedEncodingException instead of panicking on unknown charsets

[Jun025]

What

• Adds java.io.UnsupportedEncodingException (parent java.io.IOException), following the existing exception-class conventions (eof_exception etc.), registered in loader.rs.
• Converts the three unimplemented!() charset panics — String decode/encode (string.rs:787/:797) and InputStreamReader.read() (input_stream_reader.rs:115) — into thrown UnsupportedEncodingException with the offending charset name as the message.
• Unifies the String↔Reader charset support: both now resolve through a shared java_runtime::charset::Charset (UTF-8 / EUC-KR family / ISO-8859-1 / US-ASCII + aliases). InputStreamReader previously accepted only literal UTF-8/EUC-KR, so System.setProperty("file.encoding", "ISO-8859-1") panicked every subsequent read(). No decoder logic was duplicated: the reader's incremental path wraps the same tables (encoding_rs decoders + byte→char for the single-byte sets).

Necessary side fixes

• System.setProperty was declared (...)Ljava/lang/Object; but the JDK signature returns String — javac-compiled fixtures failed with NoSuchMethodError. Fixed the proto and the jvm bootstrap caller (jvm/src/jvm.rs). Properties.setProperty correctly stays Object.
• Added Throwable.getMessage() (was missing entirely), needed to verify the exception message from Java code.

Evidence

• Before: the three new Rust tests hit unimplemented!() process panics (not implemented: unsupported charset: UTF-16 / Shift_JIS).
• After: all throw catchable Java exceptions; is_instance checks confirm UnsupportedEncodingException and IOException in the hierarchy, and getMessage() returns the charset name.
• New fixture test_data/UnsupportedCharset (javac --release 21, no invokedynamic/StringBuilder) proves Java-side try { … } catch (UnsupportedEncodingException e) actually catches for getBytes("UTF-16"), new String(bytes, "Shift_JIS"), and the file.encoding=UTF-16 reader path — and that file.encoding=ISO-8859-1 now reads aéb correctly.
• cargo test --all fully green (124 java_runtime tests + all fixtures), cargo fmt --check, cargo clippy --all and --target wasm32-unknown-unknown with -D warnings clean.

Non-goals (per ticket)

• No new real encodings (UTF-16/Shift_JIS remain unsupported — now rejected per spec instead of trapping).
• No java.nio.charset API.
• Known pre-existing issue left out of scope (noted in STATE.md): the reader recreates its stream decoder per read(), so multibyte sequences split across buffer boundaries can be lost for EUC-KR.

🤖 Generated with Claude Code