rucaja
rucaja copied to clipboard
kud1ing
Calling the JVM from Rust via JNI
.. where appropriate. This would give us an opportunity to indicate why something fails and helps us get rid of some `panic`s.
We use `unwrap()` in some places where the result should "in theory" always be existant. We should handle those unlikely cases. Consider: - bubble `None`s up in functions that return...
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...
In order to resolve Java methods, one needs to declare type signatures like `"(Ljava/lang/Object;)V"` which is a bit unwieldy. It would be nice to have an easy way to generate...
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...
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...
It would be nice to measure the JNI/FFI overhead.
`JNI_VERSION_1_8` is currently hard-coded in `jvm::new()`. Make JNI/Java more configurable. Maybe even at runtime?
Consider merge with https://github.com/rawrasaur/rust-jvm See https://github.com/rawrasaur/rust-jdbc/issues/1