Bump jni-sys to 0.4.0 and jni to 0.22

[MarijnS95]

https://github.com/jni-rs/jni-sys/releases/tag/v0.4.0
https://github.com/jni-rs/jni-rs/releases/tag/v0.22.0

[MarijnS95]

Expected a local compiler error, but upon closer inspection jni is only used in a doc-example. Let's double-check that the CI catches this, though we'll then block on jni-rs/jni-rs#478.

[MarijnS95]

It's not here yet, but I've prepared this PR for jni 0.22 (except possible Rust code changes) so that it should™ be as trivial as re-running the CI to get this merged, when that release happens.

[rib]

Cool, I'd like to make a jni release soon but if I'm honest I'm not currently expecting it to happen before the 0.5 release of android-activity or winit 0.29.

[MarijnS95]

Sure, just keep in mind that that's going to be a hassle for the community as the ndk won't be able to make such a breaking release for a while until winit does... We seem to be on a ± yearly breaking release schedule.

[rib]

Surely the jni / jni-sys crates are only internal deps for the ndk crate so you should be ok to bump later?

I intentionally don't expose any jni types for android-activity so it wouldn't affect semver to bump.

[MarijnS95]

Surely the jni / jni-sys crates are only internal deps for the ndk crate

This PR is marked as breaking for a reason 😉

[rib]

Surely the jni / jni-sys crates are only internal deps for the ndk crate

This PR is marked as breaking for a reason 😉

where do the ndk / ndk-sys crates currently expose jni/jni-sys types? that doesn't sound good to me and maybe we can try to remove any exposure?

[rib]

We seem to be on a ± yearly breaking release schedule

It could be nice if we could do more frequent releases and maybe not worry too much whether every release necessarily gets picked up by Winit.

[MarijnS95]

where do the ndk / ndk-sys crates currently expose jni/jni-sys types? that doesn't sound good to me and maybe we can try to remove any exposure?

Only jni-sys types. Quite a few JNIEnv/jobjects in constructors. jni should only be used for a doc-example.

It could be nice if we could do more frequent releases and maybe not worry too much whether every release necessarily gets picked up by Winit.

We could, but it's annoying to have a mismatch between all crates that are so intertwined with windowing systems.

[rib]

where do the ndk / ndk-sys crates currently expose jni/jni-sys types? that doesn't sound good to me and maybe we can try to remove any exposure?

Only jni-sys types. Quite a few JNIEnv/jobjects in constructors. jni should only be used for a doc-example.

I was pondering for a second whether we could do a 0.3.x release of the jni-sys crate with the semver trick. That's a tempting solution but really the JNIEnv type completely changed between jni-sys 0.3 and 0.4.

That's awkward in the sense that for 99% of things (and probably all the ndk crate usage) you only care about passing around an opaque pointer and probably don't ever dereference the JNIEnv pointer type.

[MarijnS95]

@rib yeah we don't look at the innards of the type. Having a type-safe definition does help things not getting mixed up, though.

[ErichDonGubler]

This is released now! 🎉

[oscargus]

In which way is this actually breaking? Nothing is change in the ndk API as far as I can tell. Also, jni-sys 0.3.1 depends on jni-sys 0.4, so currently both versions are required.

In the interest of getting the number of transitive dependencies down for upstream projects, it would be nice to get this in.

[rib]

Updating to jni-sys 0.4 will be a breaking change for any of the unsafe from_jni APIs, such as Bitmap::from_jni that expose the jni_sys::JNIEnv type (from jni-sys 0.3) in the public API.

jni-sys 0.3 uses the semver trick to re-export the types like jobject, jint, jlong etc from jni-sys 0.4 that are backwards compatible but some jni-sys 0.4 types like jvalue, jboolean and JNIEnv are not backwards compatible.

Specifically the JNIEnv type changed from being a struct definition into a union that makes it explicitly clear which JNI functions exist for a specific version of JNI.

In the interest of getting the number of transitive dependencies down for upstream projects, it would be nice to get this in.

Note that at least in this case, there's essentially zero cost to pulling in multiple version of the jni-sys crate. jni-sys only contains type definitions to match the C ABI of jni.h and the only code to compile will be for Debug trait implementations for some of those types. There's no actual logic to compile apart from a few #[derive()] traits.