生锈 – 变量具有不同的生命周期,它们应该具有相同的生命周期

2023年5月5日 274次阅读

为了学习Rust,我正在写一个包装JNI的
library.我遇到了很多终身问题并且勇敢地与编译器进行了斗争以解决它们,但是我只是放弃了这个问题.这是问题所在.

现在,JNI是Java虚拟机的接口,因此每个java对象都必须绑定到VM.为了做到这一点,我创建了“VM指针”类型的JavaVM,它主要只是指针的包装器和创建JavaEnv对象的接口,它们只是JNIEnv *的包装器,也是一个更安全的接口的提供者.大多数JNI方法.

为了声明JavaEnv对象与VM绑定,我执行了以下操作：

pub struct JavaEnv<'a> {
    phantom: PhantomData<&'a JavaVM>,
    ...
}

现在,如果我理解正确的话,所有JavaEnv对象将在生命周期中与某个JavaVM对象绑定,并且不会比它更长,这正是我想要的.

JavaEnv – 是一个用于操作java对象(以及其他一些东西)的接口.现在,所有类型的JNI对象都实现了一个特征：

pub trait JObject<'a>: Drop {
    fn get_env(&self) -> &'a JavaEnv<'a>;
    ...
}

而且他们自己看起来像这样：

pub struct JavaObject<'a> {
    env: &'a JavaEnv<'a>,
    ...
}

pub struct JavaClass<'a> {
    env: &'a JavaEnv<'a>,
    ...
}

现在,如果我再次正确理解,所有JavaObject-s将在生命周期内绑定到某个JavaEnv对象,而后者又与JavaVM对象相关联.

最后,Java是具有默认引用语义的语言,因此对象比较只是一个浅参考比较,我想在Rust接口中反映它：

impl<'a, R: 'a + JObject<'a>> PartialEq<R> for JavaObject<'a> {
    fn eq(&self, other: &R) -> bool {
        self.get_env().is_same_object(self, other)
    }
}

impl<'a, R: 'a + JObject<'a>> PartialEq<R> for JavaClass<'a> {
    fn eq(&self, other: &R) -> bool {
        self.get_env().is_same_object(self, other)
    }
}

pub fn JavaEnv::is_same_object<T1: 'a + JObject<'a>, T2: 'a + JObject<'a>>(&self, obj1: &T1, obj2: &T2) -> bool {
    unsafe {
        ((**self.ptr).IsSameObject)(self.ptr, obj1.get_obj(), obj2.get_obj()) == JNI_TRUE
    }
}

这不起作用.这是一个测试：

let (cls, cap) = JavaClass::find(&env, "java/lang/String", cap).unwrap();
let (obj /*of class java/lang/String*/, cap) = cls.alloc(cap).unwrap();
let cls1 /*also java/lang/String*/ = obj.get_class(&cap);
assert!(cls1 == cls); 
let (sobj /*also of java/lang/String*/, cap) = JavaString::new(&env, "hi!", cap).unwrap();
assert!(cls1 != sobj);
let scls /*also java/lang/String*/ = sobj.get_class(&cap);
assert!(scls == cls1);
assert!(scls == cls);
// TODO: somehow these cls1, scls and cls have different lifetimes (or not?)
// So those two asserts do not compile!!
assert!(cls1 == scls);
assert!(cls == scls);

要“修复”这个我必须更改eq代码：

impl<'a, 'b, R: 'b + JObject<'b>> PartialEq<R> for JavaObject<'a> {
    fn eq(&self, other: &R) -> bool {
        self.get_env().is_same_object(self, other)
    }
}

impl<'a, 'b, R: 'b + JObject<'b>> PartialEq<R> for JavaClass<'a> {
    fn eq(&self, other: &R) -> bool {
        self.get_env().is_same_object(self, other)
    }
}

pub fn JavaEnv::is_same_object<'b, T1: 'a + JObject<'a>, T2: 'b + JObject<'b>>(&self, obj1: &T1, obj2: &T2) -> bool {
    unsafe {
        ((**self.ptr).IsSameObject)(self.ptr, obj1.get_obj(), obj2.get_obj()) == JNI_TRUE
    }
}

但我不想比较附加到不同VM的JObject！
而且,更多：我只是不知道,这些对象如何最终具有不同的生命周期参数？它们都是从相同的JavaEnv获得的,因此也是相同的JavaVM！

所以,问题是：我做错了什么,为什么会这样,以及如何解决这个问题？

最佳答案 我相信你的基本前提是有问题的.看看这个示例代码：

fn are_equal<'a>(a: &'a u8, b: &'a u8) -> bool {
    *a == *b
}

fn main() {
    let a = 42;

    {
        let b = 84;
        println!("{}", are_equal(&a, &b));
    }
}

在这里,我们有一个方法,它带有两个带有参数’a’的参考参数.但是,您可以清楚地看到a和b的实际生命周期(在main中)不一样 – 由于块结束而超出b.

所需要的只是有一些生命周期可以统一两个参数,并且有 – 内部块的范围.这并不意味着整个生命周期必须完全相同.

点赞