Rust bindings to the Java Native Interface — JNI

Overview

Build Status Docs Crates.io

JNI Bindings for Rust

Join the chat at https://gitter.im/jni-rs/Lobby

This project provides complete JNI bindings for Rust, allowing to:

  • Implement native Java methods for JVM and Android in Rust
  • Call Java code from Rust
  • Embed JVM in Rust applications and use any Java libraries

See the docs for more details.

Example

cd example
make

Contribution

See the Contribution Guide for details.

License

Licensed under either of

Comments
  • Add support for accessing long array elements

    Add support for accessing long array elements

    Overview

    When using the crate, I couldn't find a way of accessing long array elements in a convenient away. I had a look at JNIEnv#get_byte_array_elements and figured that we can add a similar approach for accessing long arrays.

    Definition of Done

    • [x] There are no TODOs left in the code
    • [x] Change is covered by automated tests
    • [x] The coding guidelines are followed
    • [x] Public API has documentation
    • [x] This change is not breaking or mentioned in the Changelog
    • [x] The continuous integration build passes
    hacktoberfest-accepted 
    opened by s1ck 30
  • Find and load the JVM library using java-locator and libloading

    Find and load the JVM library using java-locator and libloading

    Overview

    This PR adds the feature invocation-dyn. When this feature is enabled, JavaVM::new will discover the location of the JVM shared library using the java-locator crate and load it using the libloading crate, instead of relying on the system dynamic linker.

    That way, there's no need to add the location of the JVM shared library to $LD_LIBRARY_PATH or %Path%, making it much easier to run a program that uses the Invocation API. With the invocation-dyn feature enabled, this crate's tests all run successfully (on my Linux and Windows machines, at least) without having to run the test_profile script. (I don't have a Mac to test on at the moment.)

    This PR also adds JavaVM::with_libjvm, which takes the location of the JVM shared library from the caller instead of using java-locator.

    Breaking Changes

    Because the java-locator and libloading calls can both fail, JavaVM::new now returns Result<Self, StartJvmError>. StartJvmError wraps java_locator::errors::Error and libloading::Error in addition to jni::errors::Error. Code that expects it to return Result<Self, jni::errors::Error> will have to be updated.

    Question

    Do you want to keep the original linking scheme? I'm not sure if there are some situations where it's better to link with the JVM shared library at build time (the original invocation feature) instead of discovering and loading it at run time (the invocation-dyn feature), so I kept both. On the other hand, removing the original linking scheme would simplify both the code (build.rs, test_profile) and the documentation of this crate.

    Because I don't know if we're keeping both, I haven't yet fully documented the new feature. Please let me know which way you want to proceed, and I'll finish the documentation.

    Definition of Done

    • [x] There are no TODOs left in the code
    • [x] Change is covered by automated tests
    • [x] The coding guidelines are followed
    • [x] Public API has documentation
    • [x] User-visible changes are mentioned in the Changelog
    • [x] The continuous integration build passes
    opened by argv-minus-one 23
  • Get array elements error

    Get array elements error

    Get array elements test are failing:

    The error is:

    ReleasePrimitiveArrayCritical: release array failed bounds check, incorrect pointer returned ? array: 0x00007f4de007bc40 carray: 0x00007f4dd8001260
    GuardedMemory(0x00007f4de445c420) base_addr=0x00007f4dd8001240 tag=0x00007f4dd8001720 user_size=24 user_data=0x00007f4dd8001260
      Header guard @0x00007f4dd8001240 is BROKEN
      Trailer guard @0x00007f4dd8001278 is OK
      User data appears to have been freed
    FATAL ERROR in native method: ReleasePrimitiveArrayCritical: failed bounds check
    
    opened by maurolacy 22
  • Checked version of JNIEnv::get_string

    Checked version of JNIEnv::get_string

    Overview

    This PR:

    • Renames JNIEnv::get_string to JNIEnv::get_string_unchecked, and marks it unsafe
    • Adds a new JNIEnv::get_string which checks whether the object passed in is actually a java.lang.String
    • Adds a new error variant describing that the type of the parameter passed in is incorrect.

    See also: #328

    This PR is backwards compatible, though the code will become slightly slower due to the addition of the class check

    Open questions:

    • Can we optimize the find_class call for java/lang/String to be put in a once cell? Or must the lifetime of the JClass be tied to the JNIEnv's lifetime?

    Definition of Done

    • [x] There are no TODOs left in the code
    • [x] Change is covered by automated tests
    • [X] The coding guidelines are followed
    • [X] Public API has documentation
    • [x] User-visible changes are mentioned in the Changelog
    • [ ] The continuous integration build passes
    opened by TobiasDeBruijn 18
  • impl Default for JObject/JString/jobject/jstring/etc.

    impl Default for JObject/JString/jobject/jstring/etc.

    There's a number of types that could benefit from having the Default trait. I've noted at least:

    JObject JString jobject jstring

    ... but I suspect that most of the raw/object types could safely implement this.

    help wanted :heart: 
    opened by mattfs 16
  • Add generic get_array_elements()

    Add generic get_array_elements()

    Overview

    This is proof-of-concept code for implementing a "generic" get_array_elements() method. This is the result of a series of comments / talks, in #272 and #237.

    If you think this has merit, it's interesting, or useful, I can follow up with implementing the rest of the methods, i.e. release/ commit_array_elements, and the auto versions.

    I don't particularly like the approach used here, but pulling this anyway, because:

    • There can be better ways to do it, and we can maybe realise them here.
    • This can still be useful, in the sense that it can be converted into a macro, and used in other parts of the code base, to simplify not only these, but also similar methods.

    Please let me know what you think.

    Definition of Done

    • [x] There are no TODOs left in the code
    • [x] Change is covered by automated tests
    • [x] The coding guidelines are followed
    • [x] Public API has documentation
    • [ ] User-visible changes are mentioned in the Changelog
    • [x] The continuous integration build passes
    opened by maurolacy 15
  • Add draft tutorial for jni programming

    Add draft tutorial for jni programming

    Hi there, this is a followup draft from #222 . I'd like to work with you on the content here. A few others contributed to these materials as well. :)

    Overview

    Add a tutorial that introduces JNI programming with jni-rs. Build with mdbook to get a preview. One of the goals of the book is to have the reader do stuff and think about JNI/FFI in exercises. At the moment, it introduces JNI with division, debugging, and a native Counter implementation. You will see TODOs as you reach the end of the tutorial, especially on Cleaners.

    Definition of Done

    • [x] There are no TODOs left in the code
    • [ ] Everyone is happy enough with writing style and content
    • [x] The material is tested on Windows
    • [x] The material is tested on Linux
    • [x] The material is tested on OSX
    • [ ] The authors tag is filled in
    • [ ] Change is covered by automated tests
    • [ ] The coding guidelines are followed
    • [x] Public API has documentation
    • [x] This change is not breaking or mentioned in the Changelog
    • [ ] The continuous integration build passes
    opened by johnwalker 13
  • Adds support for setting a global class loader

    Adds support for setting a global class loader

    New functions:

    • register_class_loader to register a global class loader
    • unregister_class_loader to unregister a global class loader

    The global class loader will be used by find_class, instead of JNIEnv::FindClass.

    Overview

    Please describe your changes here and list any open questions you might have.

    Definition of Done

    • [x] There are no TODOs left in the code
    • [ ] Change is covered by automated tests
    • [ ] The coding guidelines are followed
    • [x] Public API has documentation
    • [x] This change is not breaking or mentioned in the Changelog
    • [ ] The continuous integration build passes
    enhancement 
    opened by bkchr 13
  • Remove `get_string_utf_chars` and `release_string_utf_chars` from `JNIEnv`

    Remove `get_string_utf_chars` and `release_string_utf_chars` from `JNIEnv`

    Overview

    This PR updates the documentation for JNIEnv::get_string_utf_chars, providing more details on safety and adding error documentation. This PR also marks the function as unsafe

    Open questions

    • Do we want to rename this function to get_string_utf_chars_unchecked and add a checked variant, like done with get_string in #370?
    • Do we want to add a newtype wrapper around the pointer with a Drop impl to avoid the potential memory leak?

    See also: #371

    Definition of Done

    • [x] There are no TODOs left in the code
    • [x] Change is covered by automated tests
    • [X] The coding guidelines are followed
    • [X] Public API has documentation
    • [x] User-visible changes are mentioned in the Changelog
    • [x] The continuous integration build passes
    opened by TobiasDeBruijn 11
  • Fixed calculation of buffer length provided to Get*ArrayRegion() and Set*ArrayRegion() JNI functions

    Fixed calculation of buffer length provided to Get*ArrayRegion() and Set*ArrayRegion() JNI functions

    Overview

    Fixed calculation of buffer length provided to Get*ArrayRegion() and Set*ArrayRegion() JNI functions.

    Fixes #142.

    Definition of Done

    • [x] There are no TODOs left in the code
    • [ ] Change is covered by automated tests
    • [x] The coding guidelines are followed
    • [x] Public API has documentation
    • [x] This change is not breaking or mentioned in the Changelog
    • [ ] The continuous integration build passes
    opened by koutheir 11
  • `JNIEnv.call_static_method_unchecked` does a lookup on the `class` argument, which calls `get_object_class`.

    `JNIEnv.call_static_method_unchecked` does a lookup on the `class` argument, which calls `get_object_class`.

    This means that you cannot pass either a JObject::null() or a class id to call_static_method_unchecked, you need to pass an instance of the target class.

    I believe that the call to lookup should be removed to make it possible to invoke static methods without an available instance.

    opened by s1341 10
  • Fix use-after-free (#392) and local reference leaks (#109)

    Fix use-after-free (#392) and local reference leaks (#109)

    Overview

    This PR has the changes discussed in #392. I believe it's finally ready to merge.

    This PR is the result of squashing a branch into a single commit. Here is the original, unsquashed branch.

    Definition of Done

    • [x] There are no TODOs left in the code
    • [x] Change is covered by automated tests
    • [x] The coding guidelines are followed
    • [x] Public API has documentation
    • [x] User-visible changes are mentioned in the Changelog
    • [x] The continuous integration build passes
    opened by argv-minus-one 13
  • Report error when run HelloWord on jdk11?

    Report error when run HelloWord on jdk11?

    $ java --version openjdk 11.0.15 2022-04-19 LTS OpenJDK Runtime Environment Zulu11.56+19-CA (build 11.0.15+10-LTS) OpenJDK 64-Bit Server VM Zulu11.56+19-CA (build 11.0.15+10-LTS, mixed mode)

    $ uname -a Darwin MacBook-Pro.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64

    javac HelloWorld.java && java -Djava.library.path=mylib/target/debug/ HelloWorld
    Exception in thread "main" java.lang.UnsatisfiedLinkError: no mylib in java.library.path: [mylib/target/debug/]
            at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2673)
            at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830)
            at java.base/java.lang.System.loadLibrary(System.java:1873)
            at HelloWorld.<clinit>(HelloWorld.java:13)
    
    
    opened by lfygh 0
  • All APIs like `env.new_*_array()` should return a `JObject` wrapper (like `JByteArray`) allowing safe JValue conversion

    All APIs like `env.new_*_array()` should return a `JObject` wrapper (like `JByteArray`) allowing safe JValue conversion

    Particulary to be able to call a methode with a byte array in parameter. It was possible in JNI 0.19 thanks to into but the new conversion methode doesn't work with jbyteArray.

    e.g: jni-rs 0.19

        let buffer = env.new_byte_array(asset_size)?; 
        env.call_method(asset_stream, "read", "([B)I", &[buffer.into()])?;
    
    opened by EliseChouleur 2
  • Remove useless generic argument in `define_unnamed_class`

    Remove useless generic argument in `define_unnamed_class`

    .. This is a breaking change, though

    Overview

    see title

    Definition of Done

    • [ ] There are no TODOs left in the code
    • [ ] Change is covered by automated tests
    • [ ] The coding guidelines are followed
    • [ ] Public API has documentation
    • [ ] User-visible changes are mentioned in the Changelog
    • [ ] The continuous integration build passes
    opened by fee1-dead 1
  • Update libloading requirement from 0.6 to 0.7

    Update libloading requirement from 0.6 to 0.7

    Updates the requirements on libloading to permit the latest version.

    Commits

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 0
  • `JNIEnv::{push,with}_local_frame` can free `JObject`s before their lifetime ends (use-after-free)

    `JNIEnv::{push,with}_local_frame` can free `JObject`s before their lifetime ends (use-after-free)

    JNIEnv::{push,with}_local_frame can cause JObjects to be freed before their lifetime ends, potentially resulting in use-after-free bugs and undefined behavior.

    Proof of concept:

    use jni::{*, objects::*};
    
    fn main() {
    	// Initialize JVM.
    	let jvm = JavaVM::new(
    		InitArgsBuilder::new()
    		.version(JNIVersion::V8)
    		.option("-Xcheck:jni")
    		.build()
    		.unwrap()
    	).unwrap();
    
    	let env = jvm.attach_current_thread().unwrap();
    
    	// Construct an object inside a local reference frame, but leak the reference out of that frame.
    	let mut obj: Option<JObject<'_>> = None;
    
    	env.with_local_frame(2, || {
    		obj = Some(env.new_object(
    			"java/lang/Integer",
    			"(I)V",
    			&[42.into()],
    		).unwrap());
    
    		Ok(JObject::null())
    	}).unwrap();
    
    	// Try to call a method on it. This will crash.
    	let answer = env.call_method(
    		obj.unwrap(),
    		"intValue",
    		"()I",
    		&[],
    	).unwrap().i().unwrap();
    
    	println!("The answer is {answer}.");
    }
    

    The lifetimes of JObjects are not limited by local reference frames. They have the lifetime of the JNIEnv that created them, which is longer than the lifetime of a local reference frame created with that same JNIEnv.

    This seems difficult to fix. My first thought was to make {push,with}_local_frame take a &mut self parameter (and make JNIEnv !Copy), but then it would be impossible to have any live JObjects outside of the local frame, because Rust considers the JNIEnv already borrowed.

    We could make all local references (JObject, JClass, etc) behave like AutoLocal, that is, non-Copy and free-on-drop. Then we make {pop,push,with}_local_frame unsafe (or just remove them, since this would make local reference frames mostly unnecessary).

    Additional benefits:

    • This would solve the safety issues with AutoLocal described in #381, since there would be no (non-unsafe) way to have more than one JObject wrapping the same local reference.

    • This would fix the memory leak described in #109, since JClass is now freed upon drop too.

    • JNIEnv::delete_local_ref, which also can free JObjects before the end of their lifetime, would no longer be necessary and could be removed.

    Drawbacks:

    • This would be a pretty extensive change. Most parameters of type JObject would need to be changed to &JObject, in both this crate and user code, since it's no longer Copy. Similarly, trait bounds like T: Into<JObject> would have to be changed, perhaps to T: AsRef<JObject> (and add impl<'a> AsRef<JObject<'a>> for JObject<'a> and every type that wraps it).

    • JObject and friends no longer implement Copy or Clone. From now on, the only way to duplicate a JObject is with JNIEnv::new_local_ref. I'm not sure whether that would be a nuisance or not, but if it is, then we could make it less of one by adding a new method pub fn clone<'b>(&self, env: JNIEnv<'b>) -> Result<_<'b>> to each of these types.

    What do you think? Would you like me to do this?

    opened by argv-minus-one 57
Releases(v0.20.0)
  • v0.20.0(Oct 18, 2022)

    Added

    • Default trait implemented for JObject, JString, JClass, and JByteBuffer (#199)
    • Debug trait implemented for JavaVM, GlobalRef, GlobalRefGuard, JStaticMethodID and ReleaseMode (#345)
    • ReturnType for specifying object return types without a String allocation. (#329)

    Changed

    • The release_string_utf_chars function has been marked as unsafe. (#334)
    • Mark JNIEnv::new_direct_byte_buffer as unsafe (#320)
    • JNIEnv::new_direct_byte_buffer now takes a raw pointer and size instead of a slice (#351 and #364)
    • JNIEnv::direct_buffer_address returns a raw pointer instead of a slice (#364)
    • The lifetime of AutoArray is no longer tied to the lifetime of a particular JNIEnv reference. (#302)
    • Relaxed lifetime restrictions on JNIEnv::new_local_ref. Now it can be used to create a local reference from a global reference. (#301 / #319)
    • JMethodID and JStaticMethodID implement Send + Sync and no longer has a lifetime parameter, making method IDs cacheable (with a documented 'Safety' note about ensuring they remain valid). (#346)
    • JFieldID and JStaticFieldID implement Send + Sync and no longer has a lifetime parameter, making field IDs cacheable (with a documented 'Safety' note about ensuring they remain valid). (#346)
    • The call_*_method_unchecked functions now take jni:sys::jvalue arguments to avoid allocating a Vec on each call to map + collect JValues as sys:jvalues (#329)
    • The From trait implementations converting jni_sys types like jobject to JObject have been replaced with unsafe ::from_raw functions and corresponding ::into_raw methods. Existing ::into_inner APIs were renamed ::into_raw for symmetry. (#197)
    • The APIs JNIEnv::set_rust_field, JNIEnv::get_rust_field and JNIEnv::take_rust_field have been marked as unsafe (#219)

    New Contributors

    • @TobiasDeBruijn made their first contribution in https://github.com/jni-rs/jni-rs/pull/332
    • @chrismooredev made their first contribution in https://github.com/jni-rs/jni-rs/pull/324
    • @xianminx made their first contribution in https://github.com/jni-rs/jni-rs/pull/350
    • @rib made their first contribution in https://github.com/jni-rs/jni-rs/pull/359
    • @kgrech made their first contribution in https://github.com/jni-rs/jni-rs/pull/355
    • @sdeleuze made their first contribution in https://github.com/jni-rs/jni-rs/pull/337
    • @Rodrigodd made their first contribution in https://github.com/jni-rs/jni-rs/pull/339
    • @tomcumming made their first contribution in https://github.com/jni-rs/jni-rs/pull/308
    • @kjvalencik made their first contribution in https://github.com/jni-rs/jni-rs/pull/320
    • @TimeToogo made their first contribution in https://github.com/jni-rs/jni-rs/pull/351
    • @jrose-signal made their first contribution in https://github.com/jni-rs/jni-rs/pull/318
    • @argv-minus-one made their first contribution in https://github.com/jni-rs/jni-rs/pull/319

    Full Changelog: https://github.com/jni-rs/jni-rs/compare/v0.19.0...v0.20.0

    Source code(tar.gz)
    Source code(zip)
  • v0.19.0(Feb 6, 2021)

    Added

    • AutoArray and generic get_array_elements(), along with get_<type>_array_elements helpers. (#287)
    • size() method to AutoArray and AutoPrimitiveArray. (#278 / #287)
    • discard() method to AutoArray and AutoPrimitiveArray. (#275 / #287)

    Changed

    • Removed AutoPrimitiveArray::commit(). (#290)
    • AutoByte/PrimitiveArray.commit() now returns Result. (#275)
    • Removed methods get/release/commit_byte/primitive_array_{elements|critical}. (#281)
    • Renamed methods get_auto_byte/long/primitive_array_{elements|critical} to get_byte/long/primitive_array_{elements|critical}. (#281)
    Source code(tar.gz)
    Source code(zip)
  • v0.18.0(Oct 27, 2020)

    Added

    • JNIEnv#define_unnamed_class function that allows loading a class without specifying its name. The name is inferred from the class data. (#246)
    • SetStatic<type>Field. (#248)
    • TryFrom<JValue> for types inside JValue variants (#264).
    • Implemented Copy for JNIEnv (#255).
    • repr(transparent) attribute to JavaVM struct (#259)

    Changed

    • ⚠️ Switch from error-chain to thiserror, making all errors Send. Also, support all JNI errors in the jni_error_code_to_result function and add more information to the InvalidArgList error. (#242)
    Source code(tar.gz)
    Source code(zip)
  • v0.17.0(Oct 10, 2020)

  • v0.16.0(Oct 10, 2020)

  • v0.15.0(Oct 10, 2020)

    Added

    • Ability to pass object wrappers that are convertible to JObject as arguments to the majority of JNIEnv methods without explicit conversion (#213)
    • JNIEnv#is_same_object implementation (#213)
    • JNIEnv#register_native_methods (#214)
    • Conversion from Into<JObject> to JValue::Object

    Fixed

    • Passing null as class loader to define_class method now allowed according to the JNI specification. (#225)
    Source code(tar.gz)
    Source code(zip)
  • v0.14.0(Oct 10, 2020)

    Changed

    • Relaxed some lifetime restrictions in JNIEnv to support the case when method, field ids; and global references to classes have a different (larger) lifetime than JNIEnv. (#209)
    Source code(tar.gz)
    Source code(zip)
  • v0.13.1(Oct 10, 2020)

  • v0.13.0(Jul 5, 2019)

    0.13 brings major improvements in thread management, allowing to attach the native threads permanently and safely; Executor for extra convenience and safety; and other improvements and fixes.

    :warning: If your code attaches native threads — make sure to check the updated documentation of JavaVM to learn about the new features!

    Added

    • JavaVM::attach_current_thread_permanently method, which attaches the current thread and detaches it when the thread finishes. Daemon threads attached with JavaVM::attach_current_thread_as_daemon also automatically detach themselves when finished. The number of currently attached threads may be acquired using JavaVM::threads_attached method. (#179, #180)
    • Executor — a simple thread attachment manager which helps to safely execute a closure in attached thread context and to automatically free created local references at closure exit. (#186)

    Changed

    • The default JNI API version in InitArgsBuilder from V1 to V8. (#178)
    • Extended the lifetimes of AutoLocal to make it more flexible. (#190)
    • Default exception type from checked java.lang.Exception to unchecked java.lang.RuntimeException. It is used implicitly when JNIEnv#throw is invoked with exception message: env.throw("Exception message"); however, for efficiency reasons, it is recommended to specify the exception type explicitly and use throw_new: env.throw_new(exception_type, "Exception message"). (#194)

    Fixed

    • Native threads attached with JavaVM::attach_current_thread_as_daemon now automatically detach themselves on exit, preventing Java Thread leaks. (#179)
    • Local reference leaks in JList, JMap and JMapIter. (#190, #191)
    Source code(tar.gz)
    Source code(zip)
  • v0.12.3(May 24, 2019)

    Added

    • From<jboolean> implementation for JValue (#173)
    • Debug trait for InitArgsBuilder. (#175)
    • InitArgsBuilder#options returning the collected JVM options. (#177)
    Source code(tar.gz)
    Source code(zip)
  • v0.12.2(May 2, 2019)

  • v0.12.1(Apr 27, 2019)

  • v0.12.0(Apr 1, 2019)

    Changed

    • JString, JMap and JavaStr and their respective iterators now require an extra lifetime so that they can now work with &'b JNIEnv<'a>, where 'a: 'b.
    Source code(tar.gz)
    Source code(zip)
  • v0.11.0(Feb 21, 2019)

    Highlights

    This release brings various improvements and fixes, outlined below. The most notable changes are:

    • :warning: null is no longer represented as an Err with error kind NullPtr if it is a value of some nullable Java reference (not an indication of an error). Related issues: #136, #148, #163.
    • unsafe methods, providing a low-level API similar to JNI, has been marked safe and renamed to have _unchecked suffix. Such methods can be used to implement caching of class references and method IDs to improve performance in loops and frequently called Java callbacks. If you have such, check out the docs and one of early usages of this feature.

    Added

    • Invocation API support on Windows and AppVeyor CI (#149)

    Changed

    • push_local_frame, delete_global_ref and release_string_utf_chars no longer check for exceptions as they are safe to call if there is a pending exception (#124):

      • push_local_frame will now work in case of pending exceptions — as the spec requires; and fail in case of allocation errors
      • delete_global_ref and release_string_utf_chars won't print incorrect log messages
    • Rename some macros to better express their intent (see #123):

      • Rename jni_call to jni_non_null_call as it checks the return value to be non-null.
      • Rename jni_non_null_call (which may return nulls) to jni_non_void_call.
    • A lot of public methods of JNIEnv have been marked as safe, all unsafe code has been isolated inside internal macros. Methods with _unsafe suffixes have been renamed and now have _unchecked suffixes (#140)

    • from_str method of the JavaType has been replaced by the FromStr implementation

    • Implemented Sync for GlobalRef (#102).

    • Improvements in macro usage for JNI methods calls (#136):

      • call_static_method_unchecked and get_static_field_unchecked methods are allowed to return NULL object
      • Added checking for pending exception to the call_static_method_unchecked method (eliminated WARNING messages in log)
    • Further improvements in macro usage for JNI method calls (#150):

      • The new_global_ref() and new_local_ref() functions are allowed to work with NULL objects according to specification.
      • Fixed the family of functions new_direct_byte_buffer(), get_direct_buffer_address() and get_direct_buffer_capacity() by adding checking for null and error codes.
      • Increased tests coverage for JNIEnv functions.
    • Implemented Clone for JNIEnv (#147).

    • The get_superclass(), get_field_unchecked() and get_object_array_element() are allowed to return NULL object according to the specification (#163).

    Fixed

    • The issue with early detaching of a thread by nested AttachGuard. (#139)
    Source code(tar.gz)
    Source code(zip)
  • v0.10.2(Sep 11, 2018)

    Changelog

    Added

    • JavaVM#get_java_vm_pointer to retrieve a JavaVM pointer (#98)
    • This changelog and other project documents (#106)

    Changed

    • The project is moved to an organization (#104)
    • Updated versions of dependencies (#105)
    • Improved project documents (#107)

    Fixed

    • Crate type of a shared library with native methods must be cdylib (#100)
    Source code(tar.gz)
    Source code(zip)
Owner
null
Calling the JVM from Rust via JNI

Rucaja (Rust calls Java) Calling JVM code from Rust via JNI. Usage JNI calls are about 10-20 times slower than regular JVM instructions. It is adviced

null 31 Sep 27, 2022
Rust definitions corresponding to jni.h.

jni-sys Documentation Rust definitions corresponding to jni.h. License Licensed under either of Apache License, Version 2.0, (LICENSE-APACHE or http:/

Steven Fackler 36 Nov 6, 2022
Run Java code from Rust!

Java Native Interface Bindings for Rust This library provides complete FFI bindings to the Java Native Interface, as well as a safe and intuitive wrap

Ben Anderson 66 Nov 28, 2022
Embedding Rust in Java

Java/Rust Example An example project showing how to call into Rust code from Java. OSX Linux Windows Requirements Java 7+ Rust (tested with 1.0, night

drrb 318 Jan 1, 2023
Guarding 是一个用于 Java、JavaScript、Rust、Golang 等语言的架构守护工具。借助于易于理解的 DSL,来编写守护规则。Guarding is a guardians for code, architecture, layered.

Guarding Guarding is a guardians for code, architecture, layered. Using git hooks and DSL for design guard rules. Usage install cargo install guarding

Inherd OS Team (硬核开源小组) 47 Dec 5, 2022
Java for Rust

j4rs j4rs stands for 'Java for Rust' and allows effortless calls to Java code from Rust and vice-versa. Features Rust to Java direction support (call

aston 355 Dec 28, 2022
Rust bindings for writing safe and fast native Node.js modules.

Rust bindings for writing safe and fast native Node.js modules. Getting started Once you have the platform dependencies installed, getting started is

The Neon Project 7k Jan 4, 2023
Native webview bindings for Node.js

webview-native Native webview bindings for Node.js Installing webview-native Installing webview-native requires a supported version of Node and Rust.

SnowflakeDev Community ❄️ 7 Nov 16, 2022
Native Ruby extensions written in Rust

Ruru (Rust + Ruby) Native Ruby extensions in Rust Documentation Website Have you ever considered rewriting some parts of your slow Ruby application? J

Dmitry Gritsay 812 Dec 26, 2022
Native Ruby extensions without fear

Helix ⚠️ Deprecated ⚠️ Sadly, we have made the decision to deprecate this project. While we had hoped to bootstrap the project to a point where it cou

Tilde 2k Jan 1, 2023
Rust library to interface with Lua

hlua This library is a high-level binding for Lua 5.2. You don't have access to the Lua stack, all you can do is read/write variables (including callb

Pierre Krieger 488 Dec 26, 2022
Deno Foreign Function Interface.

deno_plugin_ffi (WIP & Need Help) Deno Foreign Function Interface. deno_ffi is a Deno plugin for loading and calling dynamic libraries using pure Java

Deno Foreign Function Interface 37 Aug 18, 2022
CARBON is an interface-centric programming language named after the concept of an allotropy.

CARBON programming language Status: just an idea CARBON is an interface-centric programming language named after the concept of an allotropy. It is an

Tim McNamara 4 Aug 18, 2022
Rust based WASM/JS bindings for ur-rust

ur-wasm-js WASM/JS bindings for the ur-rust rust library Getting started Installation Either build the library yourself with wasm-pack or install for

Lightning Digital Entertainment 5 Feb 28, 2024
A project for generating C bindings from Rust code

cbindgen   Read the full user docs here! cbindgen creates C/C++11 headers for Rust libraries which expose a public C API. While you could do this by h

Ryan Hunt 1.7k Jan 3, 2023
Automatically generates Rust FFI bindings to C (and some C++) libraries.

bindgen bindgen automatically generates Rust FFI bindings to C (and some C++) libraries. For example, given the C header doggo.h: typedef struct Doggo

The Rust Programming Language 3.2k Jan 4, 2023
Rust-JDBC bindings

jdbc A Rust library that allows you to use JDBC and JDBC drivers. Usage First, add the following to your Cargo.toml: [dependencies] jdbc = "0.1" Next,

Aurora 18 Feb 9, 2022
Lua 5.3 bindings for Rust

rust-lua53 Aims to be complete Rust bindings for Lua 5.3 and beyond. Currently, master is tracking Lua 5.3.3. Requires a Unix-like environment. On Win

J.C. Moyer 150 Dec 14, 2022
Safe Rust bindings to Lua 5.1

rust-lua Copyright 2014 Lily Ballard Description This is a set of Rust bindings to Lua 5.1. The goal is to provide a (relatively) safe interface to Lu

Lily Ballard 124 Jan 5, 2023