Support for Option<T>?

[togetherwithasteria]

Hiiii <3

Will this project support passing Option to JNI? There are many APIs in the Android Sdk that might involve nullable values, soo this would help a lot!!!

[togetherwithasteria]

I'm trying to make it myself, but it's not complete yet!!! https://github.com/EchidnaHQ/robusta

It involves lots of unholy magics like patching the jni crate itself !!

[giovanniberti]

Hi @lovelyyfiaaa, thank you for bringing up this issue! I had a look at your commits and they seem fine. Given that there is also a compiler bug that you're fighting with I don't think we can hope for a better solution for the time being.

Another option would be to special-case Option into the library, but I'm not really a fan of that.

[togetherwithasteria]

Yeah, sure!!

Umm, I think we should go with the JOption enum for now?

I too dislike it, but it seems it's the only option..

[giovanniberti]

Yeah, for now you can go on and just open a PR with JOption 💪
As a workaround maybe we can use some auxiliary traits in order to still have Option as a return type and automatically convert from JOption to Option, but for now it's ok even if you don't provide such machinery.

[stevefan1999-personal]

Is it using Optional<T>?

[sergeych]

So any idea how to cope with nullables returned from java side?

[sergeych]

as a temporary workaround I use:

fn opt<T>(r: JniResult<T>) -> JniResult<Option<T>> {
        match r {
            Ok(value) => { Ok(Some(value)) }
            Err(NullPtr(&_)) => { Ok(None) }
            Err(e) => { Err(e) }
        }
    }

it works well if java/kotlin side returns null, but it most likely will also misreport NPE on java side as returning null. See no better solution yet.

[uvlad7]

@sergeych take a look at #50 and commits above