I open this issue to track the NullPointerException in tests/java_array.rs (introduced in #22).

Starting the JVM with -Xcheck:jni gives a (slightly) better error message:

FATAL ERROR in native method: Bad global or local ref passed to JNI

Disabling -Xcheck:jni and running the test with a debug JVM the message becomes more interesting:

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/jniHandles.hpp:178
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/fpoli/hg/jdk8u/hotspot/src/share/vm/runtime/jniHandles.hpp:178), pid=15159, tid=0x00007fd6ef1ed840
#  assert(result != badJNIHandle) failed: Pointing to zapped jni handle area
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-fpoli_2017_11_21_14_33-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-amd64 compressed oops)
# Core dump written. Default location: /home/fpoli/src/rust-calls-jvm/core or core.15159
#
# An error report file with more information is saved as:
# /home/fpoli/src/rust-calls-jvm/hs_err_pid15159.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

Looking at hotspot/src/share/vm/runtime/jniHandles.hpp:178 the content is this:

inline oop JNIHandles::resolve(jobject handle) {
  oop result = (handle == NULL ? (oop)NULL : *(oop*)handle);
  assert(result != NULL || (handle == NULL || !CheckJNICalls || is_weak_global_handle(handle)), "Invalid value read from jni handle");
  assert(result != badJNIHandle, "Pointing to zapped jni handle area"); // <-- line 178
  return result;
};

The primitive java types have direct mappings in jni_sys.

So is there any convenient way to convert jstring (e.g., generated by jvm::call_static_object_method) to a "str"/"&[u8]"?

In my opinion this should be reasonable since Java String is quite special. Maybe there should be an additional parameter to keep the length?

Should we hide unsafe inside the functions or is more honest/beneficial to leak unsafe in the function declarations as it is?

Discussion from the perspective of keep leaking unsafeness:

• Pro:
  • what Rucaja does is possibly unsafe
    • the JNI is low-level and not well documented
    • but we try hard to use JNI correctly and thus everything we do should be safe, unless it is a bug
• Con:
  • forces users to deal with unsafeness

Currently there are JvmClass, JvmObject and JvmStrings to bring some compile time type safety into Rust regarding different JVM classes. Unfortunately there is some code duplication.

Come up with an optimal way to hold Java objects in a Rust type that reflect the most specific Java class.

Aspects:

• jobject is just a type alias to *mut _jobject
  • jclass, jstring etc. are just type aliases to jobject
• in the constructor of the wrapper
  • do not accept JVM null pointers
  • do not accept JVM objects of the wrong type
    • IsInstanceOf() compares a jobject with a jclass.

Options:

• Macros? See https://github.com/rawrasaur/rust-jdbc/blob/5ad63b8f06ce1ded4e5c731cbae26c69d6c4b457/src/lib.rs
  • Rust nightly not necessary anymore?
• Tuple Struct?
  • does it help to reduce code duplication?
• Generic type in conjunction with an enum?

Needs a macro to make it actually useful, but at least it's not possible to construct an invalid JVM method signature with it as far as I know.

I'm not a macro wizard yet, but at least the hard part is done. If we add const onto the function it will be able to evaluate it at compile time and hopefully simplify straight down to a string literal in the binary.

I hope I didn't put it in a silly location, I haven't dived through all the code to understand it yet. Let me know if there's a better way to do this that follows the conventions for the project.

Here I add an integration test that uses arrays built from Rucaja. Unfortunately, it fails with a NullPointerException. Either I'm doing something wrong (probably) or there is a bug in some library. Any idea?

running 1 test
Exception in thread "Thread-7" java.lang.NullPointerException
    at java.util.Arrays.binarySearch0(Arrays.java:2439)
    at java.util.Arrays.binarySearch(Arrays.java:2379)
test test_java_arrays ... FAILED

failures:

---- test_java_arrays stdout ----
    thread 'test_java_arrays' panicked at 'An exception occurred', src/jvm.rs:83:8
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
            at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
            at /checkout/src/libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
            at /checkout/src/libstd/sys_common/backtrace.rs:60
            at /checkout/src/libstd/panicking.rs:381
3: std::panicking::default_hook
            at /checkout/src/libstd/panicking.rs:391
4: std::panicking::rust_panic_with_hook
            at /checkout/src/libstd/panicking.rs:611
5: std::panicking::begin_panic
            at /checkout/src/libstd/panicking.rs:572
6: rucaja::jvm::print_and_panic_on_jvm_exception
            at src/jvm.rs:83
7: rucaja::jvm::Jvm::call_static_int_method
            at src/jvm.rs:303
8: java_array::test_java_arrays
            at tests/java_array.rs:44
9: <F as test::FnBox<T>>::call_box
            at /checkout/src/libtest/lib.rs:1480
            at /checkout/src/libcore/ops/function.rs:223
            at /checkout/src/libtest/lib.rs:141
10: __rust_maybe_catch_panic
            at /checkout/src/libpanic_unwind/lib.rs:99


failures:
    test_java_arrays

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

Is it possible to build a Java array from rucaja?

I would like to call a Java method that takes an array of strings (eg. void main(String[] args)), but I can't find how to build the `jvalue' of the array.

...

let java_string: JvmString = jvm.new_jvm_string("Hello").unwrap();

let args: Vec<jvalue> = vec![
    // ?
];

// Call the main
jvm.call_static_object_method(
    &main_class,
    &main_method,
    args.as_ptr()
);

I'm not able to test it on macOS and Windows, but I added some comments in places for someone else to make it better more easily.

I think we might want to take some influence from this: https://github.com/sfackler/rust-jni-sys/blob/master/systest/build.rs

Process 66240 launched: './target/debug/rucaja' (x86_64) Process 66240 stopped * thread #1: tid = 0x3c105d, 0x00007fffe740be80 libsystem_platform.dylib_platform_strncmp + 320, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x00007fffe740be80 libsystem_platform.dylib_platform_strncmp + 320 libsystem_platform.dylib`_platform_strncmp: -> 0x7fffe740be80 <+320>: movzbq (%rdi,%rcx), %rax 0x7fffe740be85 <+325>: movzbq (%rsi,%rcx), %r8 0x7fffe740be8a <+330>: subq %r8, %rax 0x7fffe740be8d <+333>: jne 0x7fffe740be9d ; <+349>

• [x] move Jvm::new_jvm_string() => JvmString::new()
• [x] move Jvm::get_static_method() => JvmMethod::get_static_method()
• [x] move Jvm::get_method() => JvmMethod::get_method()
• [x] move Jvm::get_constructor() => JvmMethod::new_constructor()
• [x] move Jvm::get_class() => JvmClass::new()
• [x] move Jvm::call_*() to JvmMethod
• [ ] change every struct member of type &Jvm => &JvmAttachment

NewStringUTF() produces a java.security.AccessControlContext and not a java.lang.String. An object of the same type is generated by static_method_that_returns_an_interned_string() in the example.

We probably need to write a JvmString analogous to JvmObject so that the Java string is retained using NewGlobalRef() for a longer time.

Currently it takes a lot of code in order to call a JVM method: resolve the class, resolve the method, build the arguments from Rust data, possibly convert the result back to Rust data types etc.

It would be nice to be able to do this with less code in Rust. I think being more wasteful, like resolving classes/method, constructing data with each call, is fine for the sake of convenience. Users can still opt to avoid those calls by using the current wordy interface.

The official recommendation is - and maybe we should reproduce the tip exlicitely in our documentation - is to use as few JNI calls as possible.

The signature builder from https://github.com/kud1ing/rucaja/issues/3 supports usability too.

We use unwrap() in some places where the result should "in theory" always be existant.

We should handle those unlikely cases. Consider:

• bubble Nones up in functions that return an Option. Consider using ? for Options in Rust 1.22.
• panic if JVM methods fail when we can not handle it otherwise

This won't work properly my machine as I don't have $JAVA_HOME set and I'm not on macOS.

On my system (Xubuntu 16.04), libjvm.so lives in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server. But there's a symlink to the java-8-openjdk-amd64 directory at /usr/lib/jvm/default-java/jre/lib/amd64/server. Different Linux distributions do things different ways so this might not work 100% the same outside of Debian-land.

My /etc/os-release is:

NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

The problem is that not all Linux distributions have an OS release file like this, so it's actually really hard to figure out where libjvm.so is supposed to live. But worse-case scenario we can just search through /usr/lib/jvm until we find a directory with libjvm.so in it, as most people don't have enough JVMs installed to make that unreasonably slow.

I might make a pull request soon with a fix in build.rs that'll probably work on Debians, but I don't really have anything to test it with beyond cargo test.

My code is in a multi-thread setting, inside each thread, there is a need to call jvm functions.

I find that the "jvm" instance itself cannot be constructed separately inside each thread, by loading the classpath with proper options. In this case, it will panic with a message:

 '`JNI_CreateJavaVM()` signaled an error: JVM exists already'` ...rucaja-0.4.0/src/jvm.rs:186:12

This alternative seems to be putting JVM construction code before spawning threads and then passing as parameters.

The problem is that I'm not quite sure whether this will cause data race internally at the JVM side.

Since I know little about JNI and would like to be merely a "user" of rucaja, Could you please advise?