Hi,

first of all, thanks for your project!

I just tried it on mac, and the JVM crash:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.github.drrb.javarust.GreetingsTest
Starting shouldGetAStructFromRustByValue(com.github.drrb.javarust.GreetingsTest)
Starting shouldAcceptStringParameterFromJavaToRust(com.github.drrb.javarust.GreetingsTest)
SUREFIRE-859: Hello from Rust, World
Starting shouldGetAStructFromRustByReference(com.github.drrb.javarust.GreetingsTest)
Starting shouldAcceptStringFromJavaToRustAndReturnAnotherOne(com.github.drrb.javarust.GreetingsTest)
Starting shouldAcceptAStructFromJavaToRust(com.github.drrb.javarust.GreetingsTest)
Starting shouldGetAStructFromRustContainingAnArrayOfStructs(com.github.drrb.javarust.GreetingsTest)
#
# A fatal error has been detected by the Java Runtime Environment:
#
SUREFIRE-859: #  SIGSEGV (0xb) at pc=0x00007fff98c60152, pid=6353, tid=0x0000000000001703
#
# JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [libsystem_c.dylib+0x1152]  strlen+0x12
#
SUREFIRE-859: # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/yannsimon/projects/rust/java-rust-example/hs_err_pid6353.log
#
SUREFIRE-859: # If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
/bin/sh: line 1:  6353 Abort trap: 6           /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/bin/java -Djna.nosys=true -jar /Users/yannsimon/projects/rust/java-rust-example/target/surefire/surefirebooter3340298246630967947.jar /Users/yannsimon/projects/rust/java-rust-example/target/surefire/surefire2630333911108497694tmp /Users/yannsimon/projects/rust/java-rust-example/target/surefire/surefire_08200565017308027989tmp

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.787 s
[INFO] Finished at: 2016-06-18T16:11:30+02:00
[INFO] Final Memory: 17M/211M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project java-rust-example: ExecutionException: java.lang.RuntimeException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /Users/yannsimon/projects/rust/java-rust-example && /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/bin/java -Djna.nosys=true -jar /Users/yannsimon/projects/rust/java-rust-example/target/surefire/surefirebooter3340298246630967947.jar /Users/yannsimon/projects/rust/java-rust-example/target/surefire/surefire2630333911108497694tmp /Users/yannsimon/projects/rust/java-rust-example/target/surefire/surefire_08200565017308027989tmp
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

If I can help debugging the issue, please just tell me what you need.

First of all, thank you very much for this example project! It really helped me get started on using Rust from Java.

As for the problem, greetings.rs defines GreetingSet as follows:

pub struct GreetingSet {
    // A pointer to an array of Greetings. This is converted to a Greeting.ByReference by JNA.
    greetings: Box<[Greeting]>,
    // The size of the array. We need to pass it back to Java so that we know how long the array
    // is (JNA can't guess the size). We need to do this with all arrays created in Java and read
    // in Rust (or vise-versa). This c_int is converted to a Java int by JNA.
    number_of_greetings: c_int
}

This is actually incorrect. It won't crop up if you have a single GreetingSet, but if you had a contiguous array of them, you would run into problems.

The issue is apparent when you check mem::size_of::<GreetingSet>(). On a 64-bit platform, you probably expect it to be 16: 8 for the pointer, 4 for the int, and another 4 for alignment. If you test it out, though, it will actually be 24!

It turns out that the Box<[Greeting]> is basically a struct, itself: it contains the 8-byte pointer, and an 8-byte usize size field. Then, GreetingSet (as it's currently defined) tacks on a redundant 4-byte size and 4 bytes for alignment. JNA is already reading the size as provided by the Box<[]>, not your number_of_greetings field (you can test it out by putting a junk value in there).

To sum it up, GreetingSet on the Rust side should look like this:

pub struct GreetingSet {
    // A struct that includes a pointer to an array of Greetings and a size. JNA will convert this
    // to two fields: a Greeting.ByReference and an int.
    greetings: Box<[Greeting]>,
}

As the updated comment indicates, the Java code remains the same. You could optionally use a size-dependent type (com.sun.jna.IntegerType?), but Java will break on arrays longer than Integer.MAX_VALUE, anyway.

Without this change, JNA expects GreetingSetto be 16 bytes in length, but as indicated above, it's actually 24 bytes, and this leads to improper alignment if you have a GreetingSet[].

In case it's relevant, I tested this behavior on Rust nightly (1.4).

Thank you for taking the time to put together this example project. This has been very useful for my introduction into calling Rust libs from Java. Can you please provide an example illustrating the changes required to allow a Java program to call a function declared within a Struct impl? For example, assume you add a new fn called "string" within the existing "Greeting" impl that accepts a param called length (u32 or whatever) and returns a const char * that acts as a String in Java. How would I call this on the Java side? Would I create a new "string" method in Greeting.java that matches the signature? Is this even possible? I'm trying to understand if I can preserve the OOP abstractions from Rust in Java or if I have to have all C-like flat function representations for Java/JNA to work.

What is the recommended way to communicate errors from Rust back to Java? It appears that use of the 'Result' object is the standard way to communicate errors from method invocations. Would it be idiomatic to return a Result from Rust to Java to communicate to Java if an "exception" occurred when invoking the Rust code?

In all the (super awesome) examples in this repo, it seems that Java is invoking Rust functions.

Based on your experience with this repo, is it possible to use Rust-lang to create objects from Java classes and invoke Java methods on those objects?

Caching Dependencies and Directories Travis CI can cache content that does not often change, to speed up the build process.

According to the official document Fast Finishing, if some rows in the build matrix are allowed to fail, we can add fast_finish: true to the .travis.yml to get faster feedbacks.

===================== If there are any inappropriate modifications in this PR, please give me a reply and I will change them.

Bumps junit from 4.11 to 4.13.1.

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.

This PR improves the readability of the Java code used in this example by adopting idioms introduced in Java 8 and earlier.

These changes intend to make the intent and behavior of the code more visible by reducing the amount of boilerplate code.

This change also updates various dependencies to the latest compatible minor version, in order to fix the build process on Java 8+ JDKs.