Remove rust_object_field usage from Throwable, Class, ZipFile, InputStreamReader

[dlunch]

Summary

• Throwable: Store stack trace as Java String[] instead of serialized Arc<Vec<String>> pointer
• java.lang.Class: Store class name as byte array and resolve ClassDefinition via jvm.resolve_class() on demand
• ZipFile: Store raw zip bytes in Java [B array and reconstruct ZipArchive on each access
• InputStreamReader: Store charset name as Java String and create fresh Decoder per read() call

Phase 1 of removing all put_rust_object_field / get_rust_object_field usage. Remaining usages (Thread.joinEvent, Object.waitEvent) require JVM object monitor implementation (Phase 2).

[codecov]

Codecov Report

❌ Patch coverage is 93.87755% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.79%. Comparing base (34ebc38) to head (973379e).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
...runtime/src/classes/java/io/input_stream_reader.rs	77.77%	2 Missing ⚠️
jvm/src/runtime/java_lang_class.rs	91.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #137      +/-   ##
==========================================
+ Coverage   78.74%   78.79%   +0.04%     
==========================================
  Files         178      178              
  Lines        7265     7286      +21     
==========================================
+ Hits         5721     5741      +20     
- Misses       1544     1545       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Phase 1 of removing put_rust_object_field / get_rust_object_field usage by migrating several core runtime classes to store their state in regular Java fields and reconstruct Rust-side helpers on demand, reducing reliance on embedded Rust pointers inside Java objects.

Changes:

• java.lang.Class: replaces stored Rust pointer with nameBytes and resolves the ClassDefinition by name.
• java.util.zip.ZipFile: stores ZIP contents as a Java byte array (zipData) and rebuilds ZipArchive on each access.
• java.lang.Throwable + java.io.InputStreamReader: replaces Rust-object fields with Java-level representations (String[] stack traces, charset string).

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
jvm/src/runtime/java_lang_class.rs	Resolves Rust class definitions from a stored class-name byte array instead of a Rust object field.
java_runtime/src/classes/java/lang/class.rs	Updates java/lang/Class field layout to use nameBytes rather than raw.
java_runtime/src/classes/java/util/zip/zip_file.rs	Switches ZipFile state to zipData and reconstructs ZipArchive when needed.
java_runtime/src/classes/java/lang/throwable.rs	Stores stack traces as a Java String[] instead of a Rust-side Arc<Vec<String>>.
java_runtime/src/classes/java/io/input_stream_reader.rs	Stores charset name as a Java String and instantiates a decoder during reads.

Comments suppressed due to low confidence (1)

java_runtime/src/classes/java/util/zip/zip_file.rs:146

• get_input_stream has several unwrap() calls (zip.by_name, read_to_end, and writing into the Java byte array). Any missing entry, I/O error, or buffer write error will panic the whole JVM. Please return an appropriate Java exception (e.g., java/lang/IllegalArgumentException for a missing entry name, or java/io/IOException / java/util/zip/ZipException for ZIP/I/O failures) instead of panicking.

        let data = {
            let mut zip = Self::get_zip_archive(jvm, &this).await?;
            let mut file = zip.by_name(&entry_name).unwrap();

            let mut buf = Vec::new();
            file.read_to_end(&mut buf).unwrap();

            buf
        };

        // TODO do we have to use InflaterInputStream?
        let mut java_buf = jvm.instantiate_array("B", data.len() as _).await?;
        jvm.array_raw_buffer_mut(&mut java_buf).await?.write(0, &data).unwrap();

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5529cd8d5e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

java_runtime/src/classes/java/util/zip/zip_file.rs:145

• get_input_stream still uses unwrap() on zip.by_name(...), read_to_end(...), and the Java array write. If the entry name is missing/corrupt or the ZIP data can’t be read/decoded, this will panic the whole runtime instead of returning a Java-level failure (typically null or an IOException). Please propagate these errors through Result and map them to an appropriate Java exception (or return null when the entry isn’t found, consistent with getEntry).

        let data = {
            let mut zip = Self::get_zip_archive(jvm, &this).await?;
            let mut file = zip.by_name(&entry_name).unwrap();

            let mut buf = Vec::new();
            file.read_to_end(&mut buf).unwrap();

            buf
        };

        // TODO do we have to use InflaterInputStream?
        let mut java_buf = jvm.instantiate_array("B", data.len() as _).await?;
        jvm.array_raw_buffer_mut(&mut java_buf).await?.write(0, &data).unwrap();

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.