logo

Rust crates reviews

Cryptographically verifiable, distributed dependency reviews

crate: jni-sys

https://lib.rs/crates/jni-sys/

Rust links:

Rust-lang.org

lib.rs

crates.io

docs.rs

Add the last reviewed version to Cargo.toml / [dependencies]:

jni-sys = "0.3.0"

Please, use mobile in landscape.

Filter reviews clicking on the numbers in the summary.

Full column names in tooltip hints: rating Negative, rating Neutral, rating Positive, rating Strong, thoroughness, understanding, reviews count.

Neg
Neu
Pos
Str
tho
und
rev
crate
1
1
2
1
0.3.0
1
1
2
1
crate version
rating
date
reviewer
thoroughness, understanding
jni-sys 0.3.0
positive
2019-07-30
MaulingMonkey
medium, high

Good solid FFI crate. Manual generation (I see comments!) concerns me, but upon review it looks to have been done correctly.

Verified all structs and FFI signatures against android JNI.h, with the exception of double checking that everything is marked JNICALL on windows JNI instead of just most of it.
Android JNI lacks parameter names, so I didn't sanity check those either.
Verified against %LOCALAPPDATA%\Android\Sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\sysroot\usr\include\jni.h

Detail

FileRatingNotes
src/lib.rs+1Lots of unsafe... but necessary.
.gitignore+1
.travis.yml+1
appveyor.yml+1
Cargo.toml+1
Cargo.toml.orig+1
README.md+1
OtherRatingNotes
unsafe+1Lots of it... but all necessary, and after careful review, all appears correct.
fs+1None
io+1None
docs-1Nonexistant, but of low importance (other primary references are available)
tests0Not in crate

src/lib.rs

LineRatingNotes
7+1Looks sufficiently correct to me - VS defines this as *mut c_char, but *mut c_void is close enough IMO.
10+1all verified
200native version uses more newtypes, but without inheritence maybe this is sane in Rust.
39+1verified
51+1sure
57+1
64-1DANGER - rust enum for C enum is begging for unsound if returned from FFI
71+1JNI constants here all look good
930JNINativeMethod - C version uses const char*, but the muts here aren't a big deal... I
99+1
105+1JNINativeInterface is bloody huge, but all methods appear to match in name, position, and signature...
115...with the caveat that there's a lot of "system" convention when JNICALL isn't used throughout the android jni.h. However, it is used in openjdk so that's probably fine?
116I'm also assuming Option<unsafe extern "system" fn(...) -> ...> is FFI compatible with C function pointers, which might be a bad assumption.
157Native version isn't marked no return but I bet it is.
175Also, varargs functions degrade to "C" mode per https://stackoverflow.com/a/3615407
1411Reviewed all the way to here!
1413+1Sure
1421+1JNIEnv_ - Lack of impl with forwarding fns like jni.h has is vageuly annoying.
1425+1Sure
1433+1JavaVMOption - Again, mut differences, but otherwise OK. Sure.
1438+1Sure
1446+1JavaVMInitArgs - LGTM
1453+1Sure
1461+1JavaVMAttachArgs - Again, mut differences, but otherwise OK. Sure.
1467+1Sure
1475+1JNIInvokeInterface - LGTM
1501+1Sure
1507+1LHTM

© bestia.dev 2023, MIT License, Version: 2023.608.1636

Open source repository for this web app: https://github.com/bestia-dev/cargo_crev_web/