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.
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".
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.
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.
https://gist.github.com/docbrown/2b3ca251cc706975750e9d69a2724328
The main differences are:
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.
#[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::).
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.
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.
Hello,
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
Thanks
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 https://docs.oracle.com/en/java/javase/11/docs/specs/jni/index.html where on the bottom it says
Copyright © 1993, 2017, Oracle and/or its affiliates. All rights reserved.
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
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:
/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/server/libjvm.dylib
/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/lib/server/libjvm.dylib
/Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home/lib/server/libjvm.dylib
/Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home/jre/lib/server/libjvm.dylib
/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/server/libjvm.dylib
/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/include/jni.h
/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/include/jni.h
/Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home/include/jni.h
/Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home/include/jni.h
/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/jni.h
jvalue is now properly a union.Default impls have been removed from structs.jvalue's field public again to fix back compat break.JNI_GetDefaultJavaVMInitArgs and JNI_GetCreatedJavaVMs.JNI_CreateJavaVMFatalError signatureJNI_VERSION constantsOptions.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
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
Slitter is a less footgunny slab allocator Slitter is a classically structured thread-caching slab allocator that's meant to help write reliable long-
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
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
A library to compile C/C++/assembly into a Rust library/application.
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
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
bindgen bindgen automatically generates Rust FFI bindings to C (and some C++) libraries. For example, given the C header doggo.h: typedef struct Doggo
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
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
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
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
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
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
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,
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
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
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
31 Sep 27, 2022
768 Dec 30, 2022
133 Dec 5, 2022
190 Nov 12, 2022
261 Dec 1, 2022
1.3k Dec 21, 2022
5 Feb 28, 2024
1.7k Jan 3, 2023
3.2k Jan 4, 2023
4.4k Jan 7, 2023
3.5k Jan 7, 2023
296 Oct 18, 2022
66 Nov 28, 2022
318 Jan 1, 2023
18 Feb 9, 2022
150 Dec 14, 2022
124 Jan 5, 2023
47 May 4, 2022