Struct jni_glue::Env

#[repr(transparent)]
pub struct Env(_);

FFI: Use &Env instead of *const JNIEnv. This represents a per-thread Java exection environment.

A "safe" alternative to jni_sys::JNIEnv raw pointers, with the following caveats:

1. A null env will result in undefined behavior. Java should not be invoking your native functions with a null *mut JNIEnv, however, so I don't believe this is a problem in practice unless you've bindgened the C header definitions elsewhere, calling them (requiring unsafe), and passing null pointers (generally UB for JNI functions anyways, so can be seen as a caller soundness issue.)

2. Allowing the underlying JNIEnv to be modified is undefined behavior. I don't believe the JNI libraries modify the JNIEnv, so as long as you're not accepting a *mut JNIEnv elsewhere, using unsafe to dereference it, and mucking with the methods on it yourself, I believe this "should" be fine.

Example

MainActivity.java

package com.maulingmonkey.example;
 
public class MainActivity extends androidx.appcompat.app.AppCompatActivity {
    @Override
    public native boolean dispatchKeyEvent(android.view.KeyEvent keyEvent);
 
    // ...
}

main_activity.rs

use jni_sys::{jboolean, jobject, JNI_TRUE}; // TODO: Replace with safer equivalent
use jni_glue::Env;
 
#[no_mangle] pub extern "system"
fn Java_com_maulingmonkey_example_MainActivity_dispatchKeyEvent<'env>(
    _env:       &Env,
    _this:      jobject, // TODO: Replace with safer equivalent
    _key_event: jobject  // TODO: Replace with safer equivalent
) -> jboolean {
    // ...
    JNI_TRUE
}

Methods

impl Env

pub fn as_jni_env(&self) -> *mut JNIEnv