So far, I've gotten Javonet to work to calling a .net dll. It was as easy as advertised to create the javonet code.
However, in my case, I have a loop that runs approx 10 million times, and within that loop, I'm calling a dll method via Javonet. My question is: since I seem to pass the method name as a String to Javonet (based on javonet's way of doing things), I'm assuming that Javonet uses some sort of reflection to find the corresponding dll method...but wouldn't that be slow (when in a 10 million loop) especially since there are about a dozen different dlls that we've registered for javonet (or slower than solutions such as jni4net and jnbridge that seem to generate actual proxies which allow me to reference in my java code the dll method names themselves without passing the method name as a String?)
Also, is Javonet "smart" enough to copy the whole array (of primitives) into the "Java VM's memory/stack" so that when I try to access every element in the (very large, approx 2GB array) it doesn't try to do a JNI call for every element access?
Lastly, in general, is there any theoretical (or observed) reason why Javonet would be (substantively) faster/slower than jni4net or jnbridgePro in my scenario above (a loop of size 10 million and arrays of primitives that contain approx 2GB of primitive floats)?
Thanks for your good feedback!
Javonet does not make a reflection calls for each of your 10 mln calls, we do scan the types first time but all subsequent calls are done to fixed pointers to the target method.
Side note: Currently in Javonet for Java developers your string method name is still passed to .NET side (even not used in further calls) what can affect performance but we already optimized that in Javonet for .NET developers. Please contact Javonet support via email to get unofficial build with that optimization included in Java version of the product.
If you retrieve arrays of primitives Javonet will return entire array in one call so you can use it further as pure Java array without any calls back to .NET side. Javonet is also able to return mixed arrays where some items are primitives (translated to java types) and some are classes which appear as NObject instances in final Java Object[].
Intentionally we prefer JIT generation of wrappers and our reflection style API over the pre-generated wrappers to give maximum flexibility of using Javonet. So developers can decide by themselves how they use target libraries, how they optimize code to minimize cross-boundaries calls. Moreover there are no needs to install any tools or extension or run any application to use .NET DLL through Javonet. That's our goal to make sure you download single file and use any .NET code from Java in first 5 minutes.
Summarizing Javonet in fact builds the fixed wrapper on the fly during the execution. For syntax usability you can wrap your class with strongly typed interfaces and route the calls internally through Javonet API. After first call your route will get optimized and should perform averaging nine millionth of a second per call. Let us know if you have higher needs we would be pleased to address your requirements!
Sample wrapper could look like this:
Please notice the private "handle" field. If you call Javonet.setUsePrivateHandleField(bool value) before activating Javonet. When you will pass instance of such class with private handle field Javonet as argument to any .NET method Javonet will use proper .NET instance.