deps(deps): Bump jni from 0.21.1 to 0.22.4

[dependabot]

Bumps jni from 0.21.1 to 0.22.4.

Release notes

Sourced from jni's releases.

Release JNI 0.22.4

Added

• JCharSequence bindings for java.lang.CharSequence (including AsRef<JCharSequence> + .as_char_sequence() for JString) (#793)
• bind_java_type supports non_null qualifier/property for methods and fields to map null references to Error::NullPtr (#795)
• bind_java_type supports #[cfg()] attributes on methods and fields, to conditionally compile them based on features or other cfg conditions (#797)
• JValueOwned::check_null() + ::is_null() methods for ergonomic null checks on owned (returned) values (#798)
• More readable type accessors for JValueOwned, like .into_bool() instead of .z(), .into_object() instead of .l(), etc (#798)

Fixed

• jni_mangle now includes docs/macros/jni_mangle.md in the crate documentation, so the macro's documentation is visible on docs.rs and in IDEs (#799)

Full Changelog: jni-rs/jni-rs@v0.22.3...v0.22.4

Release JNI 0.22.3

No functional change in this release but it fixes the docs.rs build by bumping the simd_cesu8 dep to >= 1.1.1 which no longer has an automatically-enabled "nightly" feature that may affect the docs.rs build (1.1.x is now also MSRV compatible).

Note: Technically we shouldn't need this release (since the simd_cesu8 release alone will have fixed the build issue) but the other reason for the release is that the crates.io feature for queuing docs.rs rebuilds is not currently usable in our situation. docs.rs is currently fighting through a huge backlog of low-priority build jobs that will likely to take over a week to clear (we moved about 500 spots in two days, out of ~3k crates queued).

Release JNI 0.22.2

Note: although no breaking API change was made in this release there were some important fixes made, including a few non-trivial changes to how exceptions are handled and some important safety / soundness fixes made in the re-exported jni-macros.

For these reasons I'm going to again yank the previous 0.22.1 release after this is published, again taking into account that 0.22.1 was itself only released very recently and it should still be relatively unlikely that anyone has strictly locked in a 0.22.1 dependency.

Another benefit to yanking 0.22.1 is that it allows me to pin the jni-macros dependency via =0.22.2 in this release so that in future releases I don't need to be worried that a new jni-macros release needs to be backwards compatible with all prior jni releases (so macros can take advantage of new jni features).

Hopefully things will be smoother moving forward, now that more people have been starting to update to 0.22.x and there are more people testing it.

Added

Adds bindings for the following java.lang errors / exceptions (#767):

• JArrayIndexOutOfBoundsException (java.lang.ArrayIndexOutOfBoundsException)
• JArrayStoreException (java.lang.ArrayStoreException)
• JClassCircularityError (java.lang.ClassCircularityError)
• JClassFormatError (java.lang.ClassFormatError)
• JExceptionInInitializerError (java.lang.ExceptionInInitializerError)
• JClassNotFoundException (java.lang.ClassNotFoundException)
• JIllegalArgumentException (java.lang.IllegalArgumentException)
• JIllegalMonitorStateException (java.lang.IllegalMonitorStateException)
• JInstantiationException (java.lang.InstantiationException)
• JLinkageError (java.lang.LinkageError)
• JNoClassDefFoundError (java.lang.NoClassDefFoundError)
• JNoSuchFieldError (java.lang.NoSuchFieldError)
• JNoSuchMethodError (java.lang.NoSuchMethodError)
• JNumberFormatException (java.lang.NumberFormatException)
• JOutOfMemoryError (java.lang.OutOfMemoryError)
• JRuntimeException (java.lang.RuntimeException)
• JSecurityException (java.lang.SecurityException)

... (truncated)

Changelog

Sourced from jni's changelog.

[0.22.4] — 2026-03-16

Added

• JCharSequence bindings for java.lang.CharSequence (including AsRef<JCharSequence> + .as_char_sequence() for JString) (#793)
• bind_java_type supports non_null qualifier/property for methods and fields to map null references to Error::NullPtr (#795)
• bind_java_type supports #[cfg()] attributes on methods and fields, to conditionally compile them based on features or other cfg conditions (#797)
• JValueOwned::check_null() + ::is_null() methods for ergonomic null checks on owned (returned) values (#798)
• More readable type accessors for JValueOwned, like .into_bool() instead of .z(), .into_object() instead of .l(), etc (#798)

Fixed

• jni_mangle now includes docs/macros/jni_mangle.md in the crate documentation, so the macro's documentation is visible on docs.rs and in IDEs (#799)

[0.22.3] — 2026-03-05

Fixed

• docs.rs build: Bumps simd_cesu8 dep to >= 1.1.1 which no longer has an automatically-enabled "nightly" feature that may affect the docs.rs build (1.1.x is now also MSRV compatible) (#790)

[0.22.2] — 2026-03-01

Note: although no breaking API change was made in this release there were some important fixes made, including a few non-trivial changes to how exceptions are handled and some important safety / soundness fixes made in the re-exported jni-macros.

For these reasons I'm going to again yank the previous 0.22.1 release after this is published, again taking into account that 0.22.1 was itself only released very recently and it should still be relatively unlikely that anyone has strictly locked in a 0.22.1 dependency.

Another benefit to yanking 0.22.1 is that it allows me to pin the jni-macros dependency via =0.22.2 in this release so that in future releases I don't need to be worried that a new jni-macros release needs to be backwards compatible with all prior jni releases (so macros can take advantage of new jni features).

Hopefully things will be smoother moving forward, now that more people have been starting to update to 0.22.x and there are more people testing it.

Added

Adds bindings for the following java.lang errors / exceptions (#767):

• JArrayIndexOutOfBoundsException (java.lang.ArrayIndexOutOfBoundsException)
• JArrayStoreException (java.lang.ArrayStoreException)
• JClassCircularityError (java.lang.ClassCircularityError)
• JClassFormatError (java.lang.ClassFormatError)
• JExceptionInInitializerError (java.lang.ExceptionInInitializerError)
• JClassNotFoundException (java.lang.ClassNotFoundException)
• JIllegalArgumentException (java.lang.IllegalArgumentException)
• JIllegalMonitorStateException (java.lang.IllegalMonitorStateException)

... (truncated)

Commits

• 5ae9458 Release jni 0.22.4
• 2f954cd Fix copy&paste error s/JString::collection/JString::as_char_sequence/
• 33045a1 Release jni-macros 0.22.4
• 527703e No longer recommend passing &mut Env as the last argument
• ce7130b Import docs/macros/jni_mangle.md docs for jni_mangle macro
• d80bf23 Add more-ergonomic JValueOwned accessors
• 5ffd96a bind_java_type: Support #[cfg()] guarded methods/fields
• b498e9f bind_java_type: support non_null methods/fields
• 1f74e4b Add objects::JCharSequence binding
• 25f810d Release jni 0.22.3
• Additional commits viewable in compare view

[proggeramlug]

Holding this one, and the reasoning is worth recording because no gate anywhere will catch what's wrong with it.

jni 0.21→0.22 is a breaking release, and this PR carries no code migration. perry-ui-android uses the 0.21 API heavily — ~40 JNIEnv receivers and 44 env.pop_local_frame calls, plus a JNIEnv<'static> — and 0.22 reworks exactly those surfaces. A version bump with zero source changes is near-certain to stop that crate compiling.

And the failure would be silent. I tried to validate locally and cannot: the crate is #![cfg(target_os = "android")], so a host-target cargo check compiles an empty crate and exits 0 in 0.13s — a vacuous pass — and the real --target aarch64-linux-android check dies earlier in an unrelated C build script that needs an NDK this host does not have configured. The only place this crate actually builds is build-cross, which sets fail-fast: false — so a break there presents as a missing Android UI bundle in the release, not a red job. That is the same silent-failure shape as the macos-x86_64 matrix issue flagged on #9328.

What would let this land: the API migration in perry-ui-android done alongside the bump (mostly &mut JNIEnv receivers and the 0.22 pop_local_frame contract), validated by an actual aarch64-linux-android build — either a build-cross dispatch on the branch or an NDK-equipped host. Happy to review that when it exists; merging the bump alone trades a Dependabot nag for a silently broken release artifact.

[proggeramlug]

Update, with measurement replacing the inference above — and one correction to my own comment.

The correction: "I cannot validate locally" was wrong. This host has an NDK at ~/Library/Android/sdk/ndk/30.0.14904198; it just was not wired into the environment (and my first attempt failed on a literal * that leaked from ls output into the CC path). With the toolchain configured properly:

• origin/main (jni 0.21): the Android cross-check passes, exit 0 in ~25s — a real baseline, since the crate actually compiles for aarch64-linux-android.
• This PR as filed (jni 0.22): 1,601 compile errors. JValueGen is gone from jni::objects, GlobalRef is now generic, and the reshapes cascade through the crate's ~40 JNIEnv receivers.

So the earlier prediction is now a measured fact: merging this without a migration would break the Android leg, and silently — build-cross is fail-fast: false, so it would present as a missing Android UI bundle rather than a red job.

A migration is now in progress on a branch, using the working cross-check as its verification loop, with the constraint that the 44 env.pop_local_frame sites keep their exact frame discipline (an over-released local is a device-only use-after-free nothing here can catch). I'll land it as a PR carrying this bump plus the code changes, validated by the Android-target check, when it's done.

[proggeramlug]

Landed via #9476 — your bump plus the code migration it needed. The full story is on that PR: the bump alone fails the Android cross-check with 1,601 errors, and the migration preserves the crate's JNI frame discipline one-for-one (233→234 pop lines, the delta being the new compatibility helper's definition). Compile-verified against aarch64-linux-android with -D warnings clean; on-device behaviour under ART remains the stated unverifiable.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.