Rust definitions corresponding to jni.h.



Build Status Build status


Rust definitions corresponding to jni.h.


Licensed under either of

at your option.


Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

  • Fix crash on Windows x86 32 bits. Use correct calling conventions.

    Fix crash on Windows x86 32 bits. Use correct calling conventions.

    JNICALL on Windows is defined as __stdcall. All non varargs functions now use extern "system" in order to let Rust compiler choose stdcall on Windows x86 32 bits, for 64 bits and other platforms "system" == "C".

    opened by robmv 7
  • Add 'data' getter for the jvalue

    Add 'data' getter for the jvalue

    Compatibility has been broken in the f075705a9b092bfa5fccc01763ad89d352caeb8d commit, because public field becomes private.

    Unfortunately data field is used in the jni-rs crate. I suppose that trace! can be useful, so I propose to add getter for the data field.

    opened by stanislav-tkach 5
  • Alternative implementation

    Alternative implementation

    I was toying with my own bindings to jni.h for an Android project, but I'm probably not going to finish it. Maybe it will be useful to you. Everything related to the exported JNI_* functions is missing, because Android doesn't provide them. But they shouldn't be any different than what's in this crate already.

    The main differences are:

    1. The binding follows the C++ API more than the C API, just because it's safer type-wise. In the current jni_sys crate, reference types are just aliases of jobject. This means you can accidentally pass a jstring to a function expecting a jarray, for example, and the compiler won't complain. In my implementation, each reference type gets its own distinct underlying type and conversions must be done explicitly. There's probably a way to get some of the types to coerce to their base types (jarray to jobject, for example) without a cast, as in C++, but I didn't get that far.

    2. #[repr(C)] enum is not exactly C-compatible and it can lead to undefined behavior. So, jobjectRefType is just a C-compatible type alias and its values are module-level consts. This is what the winapi crate does and it more closely matches the original API anyway (you don't have to qualify each value with jobjectRefType::).

    3. A macro is used to generate JNIEnv and JavaVM. It also generates wrapper methods like those in the C++ API. It skips generating wrapper methods for variadic functions, although they are still defined in the v-table. I left out the *V variants because the definition of va_list varies by platform and I didn't think it was worth implementing. Unfortunately, the macro requires quite a bit of recursion and is rather slow. I'm sure there are ways to make it more efficient, though.

    4. The function pointers aren't wrapped in Option<T>. Since this is a -sys crate, favoring zero-overhead versus safety is better, in my opinion. A higher-level API can always check each pointer if it wishes, but otherwise it should be assumed that anyone using a -sys crate already knows what they're doing and won't, for example, call GetObjectRefType in a JNI 1.2 environment.

    opened by docbrown 3
  • jboolean as bool

    jboolean as bool


    It's more a question than an issue but why the jboolean value isn't considered as a bool ? My concern is that I wanted to convert a Vec via Robusta to ArrayList but u8 are considered Boolean.


    opened by EliseChouleur 1
  • No comments

    No comments

    I noticed none of the functions have any comments. I wonder wether that is because you simply didn't get around to do it or because of licensing concerns over the specification.

    The only comments for JNI functions I could find are where on the bottom it says

    Copyright © 1993, 2017, Oracle and/or its affiliates. All rights reserved.

    opened by marschall 1
  • JNI_GetCreatedJavaVMs


    When using this i get linker errors.

    The code which i used

            let mut jvm = null_mut();
            let mut found:jsize = 0;
            let mut jvm_worky = jni::sys::JNI_GetCreatedJavaVMs( &mut jvm,1,&mut found);

    error: linking with link.exe failed: exit code: 1120 | = note: "E:\Applications\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\bin\HostX64\x64\link.exe" "/DEF:C:\Users\Luna\AppData\Local\Temp\rustc2LoRkl\lib.def" "/NOLOGO" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.1byzs9aaoeboij1f.rcgu.o" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.23idsa2h5m4re0n7.rcgu.o" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.2u6h2lnoz1tkqhvf.rcgu.o" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.3tbrj5df0601ijj4.rcgu.o" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.3wjcuz3qbx2gbnyl.rcgu.o" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.3x2g0e2hwqmehtp8.rcgu.o" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.57k2cudsxfgkp4pr.rcgu.o" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.6b40e381e4fagx6.rcgu.o" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.az2bwusxx6ld47f.rcgu.o" "X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.3q890reoho8keq5z.rcgu.o" "/LIBPATH:X:\meta\dev\rust\Shimakaze\target\debug\deps" "/LIBPATH:X:\meta\dev\rust\Shimakaze\target\debug\build\libudis86-sys-cf96a0ee695f5f98\out" "/LIBPATH:C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\libwinapi-bb0ca2babfa2b4a5.rlib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\libjni-1de0fc098823e7b5.rlib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\libcesu8-a7f08aae99a2104d.rlib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\liblog-97e4acb7b95be317.rlib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\libcfg_if-b01931459ea167fc.rlib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\libcombine-cbc02205a55fd8f3.rlib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\libmemchr-665d2c8c4b4cfe12.rlib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\libbytes-49090a364b4888f6.rlib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\libthiserror-500c731b3379430b.rlib" "X:\meta\dev\rust\Shimakaze\target\debug\deps\libjni_sys-dd815645ea921445.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-2915a6598b644f05.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libpanic_unwind-600ba5171389b19e.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd_detect-9551a16e5791cc07.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librustc_demangle-9accc95c56c66c72.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libhashbrown-174e0bf43a687c69.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librustc_std_workspace_alloc-c67793bd74cdc09e.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libunwind-f28b8bbd63ca4a61.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcfg_if-4242b0a6ddf9db60.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liblibc-5c6e234e3431724c.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liballoc-ef0d43e84d25019c.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librustc_std_workspace_core-665ed95809278e59.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcore-c2100e40c13f915d.rlib" "C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcompiler_builtins-9fa99e8814512f70.rlib" "advapi32.lib" "cfgmgr32.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "opengl32.lib" "user32.lib" "winspool.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "msvcrt.lib" "/NXCOMPAT" "/LIBPATH:C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib" "/OUT:X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.dll" "/OPT:REF,NOICF" "/DLL" "/IMPLIB:X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.dll.lib" "/DEBUG" "/NATVIS:C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\intrinsic.natvis" "/NATVIS:C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\liballoc.natvis" "/NATVIS:C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\libcore.natvis" "/NATVIS:C:\Users\Luna\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\libstd.natvis" = note: Creating library X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.dll.lib and object X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.dll.exp Shimakaze.23idsa2h5m4re0n7.rcgu.o : error LNK2019: unresolved external symbol JNI_GetCreatedJavaVMs referenced in function _ZN9Shimakaze10dll_attach17h80d4ba29a706405fE X:\meta\dev\rust\Shimakaze\target\debug\deps\Shimakaze.dll : fatal error LNK1120: 1 unresolved externals

    opened by pozm 0
  • Build issues on macOS on Java 9+

    Build issues on macOS on Java 9+

    I have trouble building the project on macOS on Java 9+.

    The issue is that libjvm.dylib has been moved from ${JAVA_HOME}/jre/lib/server to ${JAVA_HOME}/lib/server

    On my system it looks like this:

    opened by marschall 1
Steven Fackler
Steven Fackler
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 bindings to the Java Native Interface — JNI

JNI Bindings for Rust This project provides complete JNI bindings for Rust, allowing to: Implement native Java methods for JVM and Android in Rust Cal

null 768 Dec 30, 2022
Slitter is a C- and Rust-callable slab allocator implemented primarily in Rust, with some C for performance or to avoid unstable Rust features.

Slitter is a less footgunny slab allocator Slitter is a classically structured thread-caching slab allocator that's meant to help write reliable long-

Backtrace Labs 133 Dec 5, 2022
A Rust crate for automatically generating C header files from Rust source file.

Please be aware that this crate is no longer actively maintained, please look into the much more feature rich cbindgen instead. rusty-cheddar rusty-ch

Sean Marshallsay 190 Nov 12, 2022
Rust-ffi-guide - A guide for doing FFI using Rust

Using unsafe for Fun and Profit A guide to traversing the FFI boundary between Rust and other languages. A rendered version is available here. This gu

Michael Bryan 261 Dec 1, 2022
Rust library for build scripts to compile C/C++ code into a Rust library

A library to compile C/C++/assembly into a Rust library/application.

Alex Crichton 1.3k Dec 21, 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
Safe interop between Rust and C++

CXX — safe FFI between Rust and C++ This library provides a safe mechanism for calling C++ code from Rust and Rust code from C++, not subject to the m

David Tolnay 4.4k Jan 7, 2023
Safe Rust bridge for creating Erlang NIF functions

Rustler Documentation | Getting Started | Example Rustler is a library for writing Erlang NIFs in safe Rust code. That means there should be no ways t

Rusterlium 3.5k Jan 7, 2023
Bridge the gap between Haskell and Rust

Curryrs Curryrs (a play on the name of Haskell Curry, rs for Rust libraries, and it's pronunciation couriers) is a library for providing easy to use b

Michael Gattozzi 296 Oct 18, 2022
Rust in Haskell FFI Example

Provides an example for using Rust in Haskell. To use this you'll need cargo, rustc, cabal and GHC installed. To execute the example run the following

Michael Gattozzi 21 Oct 1, 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
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
Zero-cost high-level lua 5.3 wrapper for Rust

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

null 47 May 4, 2022