Upgrade jni to 0.22 by djc · Pull Request #193 · rustls/rustls-platform-verifier

djc · 2025-09-13T19:27:49Z

To give feedback upstream.

complexspaces · 2025-09-13T20:28:02Z

It looks like we'll need to finally bump our MSRV with this update, as jni now has an MSRV of 1.77. This is 8 months newer, but hopefully by this point most users have moved on? Debian stable is on 1.85 so I think we're OK personally.

complexspaces · 2025-09-13T23:05:56Z

I've pushed up an initial attempt to adopt the new API of jni 0.22. It looks like there's some problems and lints that still need to be fixed but I'm out of steam for further fiddling today.

atouchet · 2026-02-17T20:50:25Z

jni 0.22 is out now.

djc · 2026-02-23T12:37:07Z

Filed:

djc · 2026-02-23T13:08:05Z

error:
       … while checking the derivation 'packages.x86_64-linux.rustls-platform-verifier'

       … while calling the 'derivationStrict' builtin
         at «nix-internal»/derivation-internal.nix:38:12:
           37|
           38|   strict = drvFunc drvAttrs;
             |            ^
           39|

       … while evaluating derivation 'rustls-platform-verifier'
         whose name attribute is located at «github:NixOS/nixpkgs/8c50662»/pkgs/stdenv/generic/make-derivation.nix:333:7

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: No hash was found while vendoring the git dependency jni-0.22.0. You can add
       a hash through the `outputHashes` argument of `importCargoLock`:

       outputHashes = {
         "jni-0.22.0" = "<hash>";
       };

       If you use `buildRustPackage`, you can add this attribute to the `cargoLock`
       attribute set.

Not sure what this means, nor am I really motivated to learn...

cpu · 2026-02-23T20:08:29Z

Not sure what this means, nor am I really motivated to learn...

The error message suggests how to fix the problem (add an explicit outputHashes for the patched crate), but it will also go away when you stop using a cargo patch to take a git dependency on jni. I would recommend ignoring it for now.

djc · 2026-02-24T10:10:20Z

Not sure what this means, nor am I really motivated to learn...

The error message suggests how to fix the problem (add an explicit outputHashes for the patched crate), but it will also go away when you stop using a cargo patch to take a git dependency on jni. I would recommend ignoring it for now.

Dropped the patch section, which is no longer necessary anyway.

djc · 2026-02-24T10:45:24Z

Okay, so the test suite doesn't compile yet, and I don't think I have enough context on how this should work to fix that.

Also, the Nix stuff fails, probably because the compiler is too old and the flake.lock rust-overlay needs an update?

djc · 2026-03-04T11:09:26Z

Upgraded the PR to 0.22.2. Still needs someone with more JVM and/or Nix context to move forward.

neunenak · 2026-03-11T16:24:43Z

I'm working on a project involving using reqwests version 0.13 on Android, and this version bump would be very helpful for integrating it into the Rust-Kotlin FFI pipeline I already have which is on jni 0.22. I'm hoping to see this get merged and released quickly.

neunenak · 2026-03-11T16:34:09Z

Okay, so the test suite doesn't compile yet, and I don't think I have enough context on how this should work to fix that.

Also, the Nix stuff fails, probably because the compiler is too old and the flake.lock rust-overlay needs an update?

Looking at the error messages in CI, it seems like there are some complaints about edition2024 not being supported by the current rust compiler version, which the flake is getting from the Cargo.toml file, which was set to 1.77 in this commit. 1.85 is the earliest version that supports edition 2024, so the version bump might need to go there to make this work.

cpu · 2026-03-11T16:43:43Z

Also, the Nix stuff fails, probably because the compiler is too old and the flake.lock rust-overlay needs an update?

Indeed, here's a fix commit that fixes the Nix CI jobs on this branch. Do you want to cherry-pick it in here, or should I open a separate PR?

(Meta note: I added that flake+CI integration and would be OK with it being removed if i'm the only thing keeping it from annoying other contributors. Fighting Android+native platform APIs doesn't spark joy and unless there's a sponsorship motivation I'd prefer to prioritize volunteering time in other Rustls repos)

neunenak · 2026-03-11T16:43:50Z

I just tried making #224 to see if that version bump might fix the CI problems, but it seems the CI pipeline won't run for me.

complexspaces · 2026-03-13T14:29:38Z

This looks good so far and I'll be finishing up my review of the global/env changes specifically Saturday morning 👍

djc · 2026-03-25T15:17:51Z

Alright, looks like this can finally pass CI. There was a problem with the earlier version of android::init_with_env() that seemingly prevented it from working in CI. Does someone want to give this a final round of review?

jplatte

As somebody who just likes their Cargo.lock tidy and has no domain knowledge of JNI, this looks good. Left a few minor comments.

.github/workflows/ci.yml

rustls-platform-verifier/src/android.rs

rustls-platform-verifier/src/tests/ffi.rs

rustls-platform-verifier/src/verification/android.rs

djc · 2026-03-25T20:47:22Z

Thanks! Would especially appreciate a review from someone with substantial Android/jni expertise.

Unfortunately the Android API exposes jni publicly.

rnikander · 2026-03-27T15:28:00Z

appreciate a review from someone with substantial Android/jni expertise.

I can't say I have substantial JNI expertise, but I've been using the API a fair amount in the last few weeks. One suggestion I'd have is to take advantage of the macros like jni_sig!, so this code:

rustls-platform-verifier/rustls-platform-verifier/src/verification/android.rs

Line 175 in d8ab444

    
           jni_sig!("(Landroid/content/Context;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;[BJ[[B)Lorg/rustls/platformverifier/VerificationResult;");

Could be more readable:

 jni_sig!((android.content.Context, JString, JString, JString[], byte[], long, byte[][]) -> org.rustls.platformverifier.VerificationResult)

I think that's correct. I didn't try to compile it.

I've also found the bind_java_type! macro to very helpful at cleaning up JNI code. The method calls become more direct instead of env.call_method(...). However, in this case, we're only calling a few methods, so I think it's fine to use env.call_static_method or env.call_method.

rib · 2026-03-30T20:37:57Z

rustls-platform-verifier/src/verification/android.rs

+        let verification_result = with_context(|cx| {
+            let byte_array_class = BYTE_ARRAY_CLASS.get(cx)?;
+            let string_class = STRING_CLASS.get(cx)?;
+            let cert_verifier_class = CERT_VERIFIER_CLASS.get(cx)?;


Note JString, JByteArray and JObjectArray are all built-in jni crate types that already handle caching their corresponding JClass.

A JObjectArray<E> accepts any Reference type as its element type, so you could do:

let array = JObjectArray::<JByteArray>::new(env, (intermediates.len() + 1).try_into().unwrap())?

and then this code wouldn't have to directly deal with looking up + caching the JClass for calling new_object_array

Note: If you need to access the (cached) JClass for a built-in jni type (such as JString) then you could use Reference::lookup_class

For the CertificateVerifier class it could be worth declaring a bind_java_type! binding something like:

bind_java_type! { CertVerifier => "org.rustls.platformverifier.CertificateVerifier", fields { code: jint, message: JString, }, methods { #[cfg(any(test, feature = "ffi-testing"))] static fn add_mock_root(mock_root: byte[]), static fn verify_certificate_chain(ctx: android.content.Context, server_name: JString, auth_type: JString, allowed_ekus: JString[], ocsp_resp: byte[], now: jlong, cert_list: byte[][]) -> "org.rustls.platformverifier.VerificationResult", } }

In addition to getting Rust method bindings like CertViewer::add_mock_root(env, mock_root)? that avoid the need for JValue argument wrappers, this would also handle the JClass caching as well as StaticMethodID and FieldID caching.

rib · 2026-03-30T20:49:17Z

rustls-platform-verifier/src/verification/android.rs

-                JavaStr::from_env(env, &s.into()).ok().map(String::from)
+                env.cast_local::<JString>(s)
+                    .and_then(|s| s.mutf8_chars(env).map(|s| s.to_str().into_owned()))
+                    .ok()


Ideally you can use a bind_java_type binding for this field so you wouldn't need the explicit JString::cast_local here but it's also worth nothing here that if you want to get a String out of a JString then you can either rely on the standard Display trait implementation (i.e. .to_string()) (with the caveat that it will return "<NULL>" for a null string since it has to be infallible) or you could use try_to_string() without having to explicitly get the mutf8_chars.

Another benefit from using a bind_java_type binding here is that it wouldn't need to do a runtime type check every time it casts the Object reference to a String reference

rib · 2026-03-30T21:06:48Z

rustls-platform-verifier/src/android.rs

+                let env = guard.borrow_env_mut();
+                env.exception_describe();
+                env.exception_clear();
+            };


This looks OK (safe) but this doesn't need to resort to any unsafe APIs here.

In this context where you're assuming that the current thread must already be attached (it wouldn't make sense to be handling a JavaException error if the thread wasn't attached), then you could use JavaVM::with_top_local_frame to effectively get a temporary &mut Env for the top JNI stack frame. This can't be used to return a local reference to the caller, but that's OK for this use case.

If you needed to create some temporary local references in order to handle the Error mapping then you could alternatively consider using JavaVM::with_local_frame() (which is also exception safe) which would push/pop a temporary stack frame to avoid leaking those references.

rib · 2026-03-30T21:14:53Z

rustls-platform-verifier/src/android.rs

-    /// <https://developer.android.com/reference/android/app/Application>
-    pub(super) fn application_context(&self) -> &JObject<'_> {
-        &self.context
+    fn load_class(&mut self, name: &'static CStr) -> Result<JClass<'env>, Error> {


Instead of needing to assume that names are ascii, it could also be reasonable to accept the name as a &'static JNIStr which is essentially a CStr with the added guarantee that it's MUTF-8 encoded.

If the same were applied to CachedClass::new so it accepted a &'static JNIStr then instead of passing a c".." CStr literal, you could pass a compile-time check literal like:

CachedClass::new(jni_str!("org.rustls.platformverifier.CertificateVerifier"));

(and that could then be passed through to here)

rib · 2026-03-30T21:32:01Z

rustls-platform-verifier/src/android.rs

-    name: &'static str,
-    class: OnceCell<GlobalRef>,
+    name: &'static CStr,
+    class: OnceCell<Global<JClass<'static>>>,


It looks like it could be possible to remove this caching utility while it's currently only used for three types, "java.lang.String", "[B" and "org.rustls.platformverifier.CertificateVerifier".

The first two types correspond to built-in jni types that already have a JClass cache that can be accessed via JString/JByteArray::lookup_class (via the Reference trait).

If a bind_java_type! binding were added for the last custom type, as sketched here: https://github.com/rustls/rustls-platform-verifier/pull/193/changes#r3012084014 that would also handle caching of the class reference too (as well as method/field IDs).

It also looks like adding a bind_java_type binding and adapting to use JObjectArray<JByteArray> may additionally avoid the need to even look up the JString / JByteArray classes explicitly since the bindings would handle those look ups internally.

rib · 2026-03-30T21:53:59Z

rustls-platform-verifier/src/android.rs

-    binding_env.with_local_frame(16, |env| {
-        let mut ctx_env = ctx_env;
+    let global = global();
+    global.vm().attach_current_thread_for_scope(|env| {


Using _for_scope here is OK, but unless there's a clear reason why this needs to avoid attachment side effects, the recommended default choice for ensuring the current thread is attached to the JVM is usually JavaVM::attach_current_thread().

In general, attach_current_thread_for_scope essentially just increases the chance of hitting a pessimal case where you keep repeatedly attaching and detaching the thread - which is non-trivial JVM operation.

If the thread is already attached then both attachment APIs are cheap and will not touch the existing attachment, which means that ::attach_current_thread() will amortised the attachment cost in case the thread uses JNI multiple times before it exits.

Note that threads attached via JavaVM::attach_current_thread will be automatically detached from the JVM when they exit.

djc requested review from complexspaces, cpu and ctz September 13, 2025 19:27

complexspaces force-pushed the jni-0.22 branch 2 times, most recently from 38af1e3 to c85fd1c Compare September 13, 2025 23:03

djc force-pushed the jni-0.22 branch from c85fd1c to 3b54a2b Compare February 23, 2026 13:03

djc force-pushed the jni-0.22 branch from 3b54a2b to cf2c727 Compare February 23, 2026 13:09

cpu mentioned this pull request Feb 23, 2026

Upgrade to jni@0.22 #222

Open

mgoldenberg mentioned this pull request Feb 23, 2026

Support TLS v1.3 on all platforms matrix-org/matrix-rust-sdk#6053

Merged

1 task

djc force-pushed the jni-0.22 branch from cf2c727 to 48a932b Compare February 24, 2026 10:09

djc force-pushed the jni-0.22 branch from 48a932b to 8b06e43 Compare February 24, 2026 10:12

djc force-pushed the jni-0.22 branch from 8b06e43 to a8f19d9 Compare February 24, 2026 10:45

mgoldenberg mentioned this pull request Mar 3, 2026

Reduce duplicate dependencies on windows-sys and windows-targets matrix-org/matrix-rust-sdk#6238

Open

djc force-pushed the jni-0.22 branch from a8f19d9 to cae50a9 Compare March 4, 2026 11:02

neunenak mentioned this pull request Mar 11, 2026

Jni 0.22 neunenak #224

Closed

cpu mentioned this pull request Mar 12, 2026

remove nix flake, CI testing #225

Merged

djc force-pushed the jni-0.22 branch 6 times, most recently from a92b18f to f027fef Compare March 23, 2026 12:55

djc mentioned this pull request Mar 24, 2026

Having a hard time with the outcome API jni-rs/jni-rs#809

Closed

djc force-pushed the jni-0.22 branch 9 times, most recently from 643a8ef to cc1891c Compare March 25, 2026 15:16

djc marked this pull request as ready for review March 25, 2026 15:16

jplatte approved these changes Mar 25, 2026

View reviewed changes

djc added 2 commits March 26, 2026 11:39

Upgrade jni to 0.22

797b2ca

Bump version to 0.7.0

d8ab444

Unfortunately the Android API exposes jni publicly.

djc force-pushed the jni-0.22 branch from 09cc927 to d8ab444 Compare March 26, 2026 10:42

rib reviewed Mar 30, 2026

View reviewed changes

Conversation

djc commented Sep 13, 2025

Uh oh!

complexspaces commented Sep 13, 2025

Uh oh!

complexspaces commented Sep 13, 2025

Uh oh!

atouchet commented Feb 17, 2026

Uh oh!

djc commented Feb 23, 2026

Uh oh!

djc commented Feb 23, 2026

Uh oh!

cpu commented Feb 23, 2026

Uh oh!

djc commented Feb 24, 2026

Uh oh!

djc commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

djc commented Mar 4, 2026

Uh oh!

neunenak commented Mar 11, 2026

Uh oh!

neunenak commented Mar 11, 2026

Uh oh!

cpu commented Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

neunenak commented Mar 11, 2026

Uh oh!

complexspaces commented Mar 13, 2026

Uh oh!

djc commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jplatte left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

djc commented Mar 25, 2026

Uh oh!

rnikander commented Mar 27, 2026

Uh oh!

rib Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

rib Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rib Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

rib Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

rib Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

rib Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

djc commented Feb 24, 2026 •

edited

Loading

cpu commented Mar 11, 2026 •

edited

Loading

djc commented Mar 25, 2026 •

edited

Loading

rib Mar 30, 2026 •

edited

Loading