Rust bindings to the Java Native Interface — JNI
License: Apache License 2.0
This project provides complete JNI bindings for Rust, allowing to:
See the docs for more details.
cd example
makeSee the Contribution Guide for details.
Licensed under either of
at your option.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Attempting to compile the code in example/mylib in the master branch leads to the following error:
error[E0599]: no method named `detach` found for type `jni::objects::GlobalRef` in the current scope
--> src/lib.rs:137:29
|
137 | let callback = callback.detach().unwrap();
| ^^^^^^
It looks like this is due to the change made in a98e71f Reimplemented GlobalRef (#66) when GlobalRef was made Send. Unfortunately I don't know enough about this to know how to fix it.
I'm dealing with a case where I need to hold a struct containing a GlobalRef inside of an Arc<...> and it's not happy with the fact that GlobalRef isn't Sync.
My understanding is that GlobalRef is both thread-agnostic and thread-safe [1], so it should be safe to make it Sync as well.
[1] http://www.latkin.org/blog/2016/02/01/jni-object-lifetimes-quick-reference/
I would like to call env.pop_local_frame(JObject::null()).
The documentation says that "resulting JObject can be NULL if result is NULL".
However, in my case pop_local_frame returns an Err(NullPtr("PopLocalFrame result")).
Shouldn't the result be Ok(something), since it's an expected behaviour?
Having tests is very useful. We could write some integration/system test that:
jni-sys or the proposed extended invocation API #60JNIEnv with JNIEnv::from_rawJNIEnv, relaying mainly on JVM builtin classesAn example of the result is here, from the Rucaja crate.
Constructor is a static method, so I made a mistake in the #29.
The implementation of call_method_unsafe (which is called from call_method) usesjni_unchecked! macro if the method return type is void or a primitive type. But if the method throws an exception, it won't be detected by the library unless either:
JNIEnv#exception_check/#exception_occurreddelete_local_ref (DeleteLocalRef) is specified as one of a few safe functions to call when there is a pending exception (= the one that do not throw). But the implementation of JNIEnv#delete_local_ref checks for exceptions after the call:
pub fn delete_local_ref(&self, obj: JObject) -> Result<()> {
non_null!(obj, "delete_local_ref obj argument");
Ok(unsafe {
jni_unchecked!(self.internal, DeleteLocalRef, obj.into_inner());
check_exception!(self.internal);
})
}
It might result in an Err when a user invokes delete_local_ref when they've already got an exception and try to delete local references.
Hello
I'm following your example. It has a signature like this:
pub extern "system" fn Java_HelloWorld_hello(env: JNIEnv,
class: JClass,
input: JString)
-> jstring {
...From looking at the signature, it seems that parameter types come from the objects module while the return value is a sys type.
How would I accept a byte array as input value instead of a JString? There's sys::jbyteArray but there doesn't seem to be a matching objects type?
I have a function signature where I want to return an object instance or null.
I tried returning an Option<jobject>, but then the Rust code panics :)
Is there a way to return a null pointer?
The crate jni_sys has renamed the field _data of struct jvalue to data, hence this crate does not compile anymore due to this line in jvalue.rs (line 54):
trace!("converted {:?} to jvalue {:?}", self, val._data);Hi,
I was wondering, since the byte java type maps to an i8, shouldn't byte array conversion return a Vec<i8> and not Vec<u8>?
It is possible to call methods on a GlobalRef?
JNIEnv::call_method takes an JObject and i don't see any way to convert between the types.
When trying to instantiate an object of the calling class of a native method, the code fails to execute and crashes the JVM with a SIGSEGV
Crash log https://hastebin.com/finariguju.tex
Relevant code https://hastebin.com/xazukoguti.js
Is there a way to create a new object from the cached GlobalRef? As far as I can see, new_object expects a class name as string only. Am I missing something?
If this is currently impossible, I can try to fix this (somehow). 😅
Both JMethodID and JStaticMethodID have lifetime associated with JNIEnv, but it isn't entirely correct:
A field or method ID does not prevent the VM from unloading the class from which the ID has been derived. After the class is unloaded, the method or field ID becomes invalid. The native code, therefore, must make sure to:
- keep a live reference to the underlying class, or
- recompute the method or field ID
This way method id should depend on class and not on JNIEnv. As far as I can see, there is no easy way to express that in the Rust code. In my code I use "hack" to workaround current restriction:
struct CachedConstructor {
pub element_class: GlobalRef,
// `static` lifetime is used here.
pub constructor_id: JMethodID<'static>,
}
impl<InnerIter> CachedConstructor {
pub fn new(env: &JNIEnv, class_name: &str) -> Result<Self> {
let class = env.find_class(class_name)?;
let element_class = env.new_global_ref(class.into())?;
let id = env.get_method_id(class_name, "<init>", "([B[B)V")?;
Ok(CachedConstructor {
element_class,
// Transmute & unsafe:
constructor_id: unsafe { mem::transmute(id) },
})
}
}Any advices on how to handle it better?
Currently check_exception! macro returns JavaException error which isn't very informative: native (rust) call stack is missed because of Result handling logic.
More details: in the situation where there are many new_object calls and some of them fail (NoSuchMethodError) it isn't clear which one caused problem.
I'm not sure what is the best way to handle such situations. Some ideas:
new_object call. This approach requires additional boilerplate.jni-rs can include in Result::Err some additional information about the JNI call context: the call stack information and method parameters. For example, when GetMethodId fails with a NoSuchMethodError, include information about the class, method name and signature.new_object method (and related ones).Additional question: perhaps, this situation isn't specific only to creating a new Java object, but it relates to the overall error handling strategy.
Is there a way to access a static field?
@jechase, @anandkunal ,
Thank you for putting together and open-sourcing Rust JNI project. We at Exonum have been using it for more than a year and are interested in its further development.
Our team is grateful to you for reviewing and integrating our patches so far, however, it seems to us the project has ceased to be your top priority recently. For this reason, I suggest moving it under a new organization “JNI-rs” and giving more people permission to integrate changes and publish new versions of it on crates.io. In this way the project can evolve, enlarge its community, acquire better maintenance and improve in quality.
We understand it takes efforts maintaining an open-source project and would like to offer help with that. As you may know, members of Exonum team — @DarkEld3r , @alexander-irbis — have contributed various fixes and improvements to Rust JNI as well as reviewed every patch submitted to the project in the last year. Our team has expertise in running open-source projects in Rust, Exonum being the most prominent example.
Please consider further development of your project in a modified manner as suggested above and let us know your thoughts on the matter. You are free to contact our team members or me directly for discussion.
CC recent contributors: @paulrouget, @daschl, @mmastrac , @fpoli , @nbaksalyar , @king6cong , @mehcode
This trait is really important to use with a code like e.display_chain().to_string().
But there is no reason to depend on this crate in every project and keep its version in sync with jni-rs.
The documentation mentions that the crate type should be set to dylib so that a shared object loadable by Java is produced. I had to set it to cdylib, dylib produces objects that link dynamically to libstd.
Currently DetachedGlobalRef attaches a native thread to the JVM in its #drop function in case when the current native thread is not attached, and immediately detaches. That prevents a memory leak, but it also makes it easy to rely on this mechanism frequently enough to introduce a performance bug and make your program come to a crawl. What makes it considerable, is that frequently enough means thousands.
@alexander-irbis did a simple benchmark that constantly attaches a native thread, calls a simple Java method, and immediately detaches it. It shows tens of thousands ops per second. Such a slow throughput occurs because JVM creates a new thread when a detached native thread calls AttachCurrentThread. The results above align well with the results I obtained with a Java benchmark which simply creates threads that do nothing and stop: JVM creates ~40K threads per second on my laptop.
I'd suggest to log a warning message in the case described above, saying that if you see it once, it's OK, if you see it frequently -- consider reading the docs and fixing your app, because:
This issue relates to DetachedGlobalRef as of v0.8.1, and a prospective new GlobalRef in #67, therefore, it's orthogonal to #66 .
Hi,
Currently, methods like https://docs.rs/jni/0.10.1/src/jni/wrapper/jnienv.rs.html#1315 take the buffer they modify as non-mutable, but they are modifying its content. I wonder if the array to modify should be passed in as &mut? I think this also applies to all other similar methods on the env.
Can the library help somehow in the generation of native proxies of Java objects?
At the moment we are using this crate https://github.com/viperproject/jni-gen (undocumented...)
Our approach inspects the JVM by reflection at Rust's compile time and generates wrappers for methods listed in a whitelist in build.rs (see here for an example). We introduced the whitelist because we choose to generate a wrapper for every inherited method, thus increasing a lot the size of the generated code. Whenever possible (that is, unambiguous) the user can leave a field empty to let the generator choose the only possible name/signature/...
An example of the generated bindings: https://viperproject.github.io/prusti-dev/viper_sys/wrappers/index.html
Some problems that we found:
The end result works fine, but there is a lot that can be improved. For example, the whitelist in build.rs may be intimidating at a first glance, the name of method parameters is not preserved, and so on.
I have a simple POJO class with an empty constructor.
public IceCandidate() { }This is what the JNI class looks like according to javap:
public class ch.dbrgn.candidateparser.IceCandidate {
public ch.dbrgn.candidateparser.IceCandidate();
...
}When I try to create a new instance for that class:
let myobj = env.new_object("ch/dbrgn/candidateparser/IceCandidate", "()V", &[]).unwrap();...then I get a native crash.
JNI ERROR (app bug): accessed stale local reference 0x5 (index 1 in a table of size 1)
art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x5
art/runtime/java_vm_ext.cc:410] native: #02 pc 0025a775 /system/lib/libart.so (_ZN3art9JavaVMExt8JniAbortEPKcS2_+740)
art/runtime/java_vm_ext.cc:410] native: #03 pc 0025aecb /system/lib/libart.so (_ZN3art9JavaVMExt9JniAbortFEPKcS2_z+74)
art/runtime/java_vm_ext.cc:410] native: #05 pc 00101211 /system/lib/libart.so (_ZN3art11ScopedCheck5CheckERNS_18ScopedObjectAccessEbPKcPNS_12JniValueTypeE.constprop.95+684)
art/runtime/java_vm_ext.cc:410] native: #06 pc 00108ac5 /system/lib/libart.so (_ZN3art8CheckJNI10NewObjectAEP7_JNIEnvP7_jclassP10_jmethodIDP6jvalue+436)
art/runtime/java_vm_ext.cc:410] native: #07 pc 000099db /data/app/ch.dbrgn.candidateparser.test-1/lib/arm/libcandidateparser_jni.so (Java_ch_dbrgn_candidateparser_CandidateParser_parseSdp+3230)
Any idea what reference that could be? I've tried to debug this for quite a while now.
I would like to call EnsureLocalCapacity, and I'm willing to contribute.
Is it fine if I add a ensure_local_capacity(&self, capacity: jint) method to JNIEnv?
When a user passes an invalid signature string (e.g., "()Ljava/lang/List" to env.call_static_method), they get an obscure error:
Parse error at 93988628020833
Unexpected `end of input`
Expected `;`
It doesn't include the input string that caused the error, but includes this huge and unique to each invocation number. Is it a formatting bug in the "combine" library that produces this error message?
This is a feature request and an another take on #80 .
Consider adding a tool that takes a Java source file with native methods or a native C header of such file, produced by javac, and turns it into a Rust-template. Basically:
X.java --> (X.rs, X-human-readable.rs)
Such a tool may produce a single template file, similar to what one currently writes by hand, or a couple of files:
nativeCreate instead of Java_com_example_company_NativePeerProxy_nativeCreate). Such methods might also enjoy some conversions that are performed by the code in intermediate file (e.g., jint -> i32, again, see #80).If there is a user-facing file, intermediate one calls its functions.
javac -h produces. Restrictions may apply on method names (e.g., method names that contain only ASCII symbols).javac -h output.javac -h output.
javac -h output.
javac..rs files by hand.The title says it all.
Is there a fully contained example to call a Java method from Rust code?
Some thing like an example found on https://github.com/rustyhorde/rsjni
This is a feature request for an additional safety net for the use-case when Java passes pointers to native objects to the native code.
Consider the following code:
// An example of Java proxy of a native object: `vec` proxy
class VecProxy {
// A handle to the corresponding native object (aka native peer).
private final long nativeHandle;
// Constructors, public methods using the native methods below:
// Creates a new `vec` and returns a pointer to it.
private static native long nativeCreate(int initialSize);
// Adds the given element to the vector.
private static native void nativeAdd(long nativeHandle, int newElement);
// Destroys the corresponding native peer.
private static native void nativeDestroy(long nativeHandle);
}The native code has to cast jlongs to the corresponding objects. If there is a bug in Java code (use-after-free, double-free, unknown-pointer, wrong-pointer-type), the app is likely to crash.
A registry of all native objects that can be used at the given moment by a pointer. Such an object checks that a native handle:
Such checks may be optional (e.g., enabled in debug builds only), and may be exposed through such interface:
to_handlecast_handledrop_handleIn Exonum Java Binding, we currently have a synchronized HashMap-based implementation.
jni-java-proxies?T to #80 , glue code may automatically convert a jlong to T and pass an instance of T to the user code.I'm trying to compile my example fasihrana/rustjni_example on windows and I'm getting the following error:
error: failed to run custom build command for `jni v0.10.1` process didn't exit successfully: `C:\Code\RUSTSTUFF\rustjni_example\target\debug\build\jni-6a065823e243d0f6\build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Failed to find libjvm.so. Try setting JAVA_HOME', C:\Users\frana\.cargo\registry\src\github.com-1ecc6299db9ec823\jni-0.10.1\build.rs:19:21 note: Run with `RUST_BACKTRACE=1` for a backtrace.
Why is it looking for libjvm.so on Windows and how do I fix that?
This is a feature request for an abstraction enabling any code to execute a lambda in some context with JNIEnv (i.e., in a native thread that is guaranteed to be attached to the JVM).
Such abstraction is useful when impelementing native proxies of Java objects:
trait Executor {
// Executes the given function in a native thread
// that is attached to the JVM (= has JNIEnv).
def <T> with_context(Function<&JNIEnv, T> function);
}
// A native proxy of a Java Foo class.
struct JavaFooProxy {
// A global reference to an instance of the Java Foo class.
foo: GlobalRef;
// An executor, allowing to call a Java method in an arbitrary moment.
executor: Executor;
// Calls Java `Foo#bar` method.
def bar() {
executor.with_context((env: &JNIEnv) -> {
env.call_method(foo, "bar", BAR_SIGNATURE, …);
}
}
}How Executor provides a context (JNIEnv) — is an implementation detail.
There might be various implementations of such an interface:
detaches them (a benign leak).In our code base, we currently have a SnailExecutor only.
Certainly not an exaustive list, please post yours:
jni-native-proxies?AutoLocal and GlobalRef?Currently there are four functions that work with bytes:
new_byte_array: takes &[i8]convert_byte_array: returns Vec<u8>new_direct_byte_buffer: takes &mut [u8]get_direct_buffer_address: returns &mut [u8]new_byte_array expects slice of signed bytes, what is more Java-like.I prefer to change new_byte_array signature (and happy to submit a patch), but that will be a breaking change. Is it OK?
Hi! Apologies if I'm missing something obvious.
It seems that as of b6463aa I can no longer compile the library for arm targets.
Trying to run cargo build --target armv7-linux-androideabi fails with
error[E0512]: transmute called with types of different sizes
--> /Users/realpassy/.cargo/registry/src/github.com-1ecc6299db9ec823/jni-0.7.0/src/wrapper/objects/jvalue.rs:53:13
|
53 | ::std::mem::transmute::<_, usize>(val)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: source type: jni_sys::jvalue (64 bits)
= note: target type: usize (32 bits)
I'm too much of a Rust n00b to say whether or not this is an intended limitation, but it seems that v0.6.1 works fine for that target.
If a Java instance method returns null, JNIEnv#call_method panics:
thread 'call_method_returning_null' panicked at 'Error: null pointer in CallObjectMethodA result
', tests/util/mod.rs:48:9
I get an UnsatisfiedLinkError with this method:
FastCompute.arrayAddRS(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/String
Rust:
#[no_mangle]
#[allow(non_snake_case)]
#[allow(unused_variables)]
pub extern "C" fn Java_FastCompute_arrayAddRS(env: JNIEnv, class: JClass, a: JObject, b: JObject) -> jstring {
[...]
}Java:
private native String arrayAddRS(Object a, Object b);My other method (FastCompute.addRS.(II)I) is working without any problems
We've developed a couple of benchmarks comparing high-level APIs to low-level C-like APIs in Rust-JNI:
call_static_method vs call_static_method_unsafe, using j.l.Math#abs.call_method vs call_method_unsafe, using j.l.Object#hashCode. The object construction is not included in the measurement.new_object vs new_object_by_id, using j.l.Object#new. The measurement includes removing the local references in the benchmark itself.I think it may be useful to upstream them so that users have an up-to-date data about their relative performance and can decide when it makes sense to them to use lower-level ones.
See also: https://developer.android.com/training/articles/perf-jni.html
I changed the example and run hello world in a loop, and memory usage keeps going up until around 165M and stops growing.
king6cong@4bedfbb#diff-cc38745d93dc48d0cd2612e5d596dad5L15
git clone -b leak https://github.com/king6cong/jni-rs
cd jni-rs
cd example/mylib && cargo build && cd -
cd example && javac HelloWorld.java && java -Djava.library.path=mylib/target/debug/ HelloWorld
This is strange, and not sure if this is a memory leak
Method with void signature ()V doesn't work:
Rust:
call_method(callback_object, "onStarted", "()V", &[JValue::Void]).unwrap()
Java:
public void onStarted();
See #76 for some background.
It would be nice to be able to define the FFI functions more like regular rust functions with rust error handling rather than as extern "C" functions. The current way of doing things forces you to manually catch Result::Err results and turn them into java exceptions (or however you want to deal with them), and to manually wrap everything in std::panic::catch_unwind (which you are doing, right?) and deal with the Result from that as well.
We could instead have a macro system that allows you to write your ffi methods such that they return the expected Result<T, E>, and then convert that into an exception or java return type as needed. It would do the same with automatically doing the catch_unwind wrapping and result management in a similar manner.
The macro system could potentially also do automatic conversions of java types (such as Strings) into their rust representations, though it should probably be possible to bypass this if desired for performance reasons.
It would be useful to support working with Object arrays. I think this just requires wrappers for
Hi guys,
How can I use 'registerNatives' to register native methods dynamically (using jni-rs)?
Our team needs a means to launch a JVM from Rust (in C JNI interface that functionality is provided by the Invocation API, that is already partly supported by jni-rs). I'd like to ask if anybody is currently working on it, and if not, if we could contribute the remaining parts? Are there any nuances we must consider when designing and implementing this functionality?
The current implementation of global references in the form of GlobalRef / DetachedGlobalRef mistakenly assumes that the reference should be attached to the thread. In fact, this is not the case, the same reference can be concurrently used in different threads at the same time.
In addition, the need to destroy an instance of GlobalRef or DetachedGlobalRef when attaching / detaching is not ergonomic, since it complicates the storage of the reference as part of the other structures.
On the other hand, the task to protect from a race condition by the type system of Rust goes beyond the scope of the functionality of GlobalRef, and ultimately is not solved, due to the possibility of creating an additional global reference to the same data (and, it seems, not can be guaranteed to be solved).
Therefore, the functionality of the references and the attachments to threads should be divided into two independent structures that might roughly look like this:
#[derive(Clone)]
struct GlobalRef {
internal: Arc<GlobalRefGuard>,
}
struct GlobalRefGuard {
vm: JavaVM,
obj: JObject<'static>,
}
#[derive(Clone)]
struct JNIEnv {
env: Rc<JNIEnvGuard>,
}
GlobalRef in such an implementation will allow to re-use the global reference, including between threads, and also automatically release it, as soon as the need for it gone. In addition, reusing an existing global reference, instead of creating a new one each time (by calling NewGlobalRef), allows speeding up in some cases, but this speedup can be neglected if dozens of other calls to JNI or heavy computing operations occurs on each copy of the reference.
The structure JNIEnv with the use of a similar pattern would be able to transparently hold the attached JVM thread, while we need it somewhere in the native thread, and detach as soon as the need for it gone (or, knowing that we will need it for a long time, we could keep it without detaching, just saving an additional copy of JNIEnv). But this is beyond the scope of this issue and requires more detailed discussion and changes in JavaVM.
A bit later I will do PR with a new implementation of GlobalRef. But, since this is a breaking change, there may be open questions that should be discussed.
For example, should the current implementation of GlobalRef + DetachedGlobalRef be deprecated and then discarded or GlobalRef should remain as it is, but renamed to AttachedGlobalRef, because someone heavily depends on it?
I'm working on a rust crate with some functions that return Result - I'm hoping use the Err values to generate exceptions for the Java caller, but I'm not confident I'm using the provided API in the intended way.
The reason I'm doubtful is I expected to be able to do something like this:
#[no_mangle]
#[allow(non_snake_case)]
pub extern "system" fn Java_MyLib_getMaybeBool(
env: JNIEnv,
class: JClass,
input: JString,
) -> jboolean {
let input: String = env.get_string(input)
.expect("Couldn't get java string!")
.into();
match get_maybe_bool(&input) {
Ok(output) => output as u8,
Err(err) => {
env.throw(err.to_string()).unwrap();
unreachable!();
}
}
} When I write this, the java caller segfaults in the Err case, hitting the unreachable!(); and then panics.
Instead, I'm returning a 0u8 following the throw, which I guess could be correct from a certain point of view (but not really). With the 0u8 return value, I see the caller get the exception and everything works how I'd think it should.
Am I missing some aspect of this? An example of throwing exceptions would be nice to have.
Sometimes it is important to manually delete the local references. I have made a simple wrapper for that:
pub struct AutoLocalRef<'a> {
object: jobject,
env: &'a JNIEnv<'a>,
}
impl<'a> AutoLocalRef<'a> {
pub fn new(env: &'a JNIEnv<'a>, object: jobject) -> Self {
Self { object, env }
}
pub fn as_obj(&self) -> JObject {
self.object.into()
}
}
impl<'a> Drop for AutoLocalRef<'a> {
fn drop(&mut self) {
if let Err(e) = self.env.delete_local_ref(self.object.into()) {
error!("Unable to delete local reference: {}", e.description());
}
}
}Typical use case:
fn make_java_object<'a>(env: &JNIEnv<'a>, value: &Value) -> Result<JObject<'a>> {
let value = AutoLocalRef::new(env, env.byte_array_from_slice(value)?);
env.new_object(
"com/project/foo/bar/baz/ClassName",
"([B)V",
&[value.as_obj().into()],
)
}This function is used for building tree-like structure, so local references must be deleted because there can be many nodes.
Questions:
jni-rs library?jobject inside and has method for conversion it to the JObject because this allows to clone internal object: many functions take JObject by value and reference must be deleted after that. Perhaps this can be handled better somehow.I'm a beginner to Rust and I have no idea how to write the equivalent Rust code of the C++ code below:
JNIEXPORT auto JNICALL Java_foo_Bar_foo(
JNIEnv *env,
jclass,
jint num,
jintArray _data) -> jintArray {
jboolean *option = nullptr;
auto len = env->GetArrayLength(_data);
auto data = env->GetIntArrayElements(_data, option);
env->ReleaseIntArrayElements(_data, data, JNI_ABORT);
auto _ret = env->NewIntArray(len);
env->SetIntArrayRegion(_ret, 0, len, ret);
return _ret;
}Sorry for my English.
JNIEnv methods accepting Desc<JClass> leak a local reference to the Class object if they create a new local reference.
If an implementation of Desc#lookup that creates a new local reference is passed to the JNIEnv methods, the created local reference will be leaked (resulting in a leak of native JVM heap and a (potential) leak of referenced Java object). E.g.,
env.call_static_method("java/lang/Math", "abs", "(I)I", &[JValue::from(-1 as jint)])will leak a single local reference to an instance of Class<java.lang.Math> created here each time it is called.
There are about two dozens of Desc#lookups in the codebase.
Such leaks can be considered benign if all created local references are freed later:
with_local_frame — freed after the last statement in that lambda.Code using affected methods in:
with_local_frame/auto_local to manage the references created by the user, it must be noted that it's not required if it performs only simple calls that do not expose any references that have to be deleted. In other words, it is reasonable to expect that the library methods do not leak — and that's the specified behaviour of the C APIs:To ensure that programmers can manually free local references, JNI functions are not allowed to create extra local references, except for references they return as the result.
See #108
There are a number of places where we ignore the returned error code from jni methods because we're already checking for a java exception being thrown.
Doing the inverse (checking error code, ignore exception) could give greater insight into why the method failed since we could return more meaningful errors than "Java exception was thrown," and the error codes are reasonably well-defined.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.