Saturday, April 17, 2010

jni4net NOT yet on Mono & Linux

I started with investigations of support for Mono on x86. The key problem is different calling convention - cdecl. My current implementation of JniLocalHandle is build on top of assumption that small structures are put onto stack same way as scalar types. But that's not valid assumption, it works just for stdcall. cdecl allocates the structure on heap and passes just pointer to the structure, no matter how big the structure is. Why I created JniLocalHandle ? Because I wanted to make strongly typed difference between JniLocalHandle and JniGlobalHandle. We could drop it and use IntPtr in order to deal with this problem. It will impact all generated proxies on C# side.
There is another problem with cdecl, because I need to put
[UnmanagedFunctionPointer(CallingConvention.xxx)]
on any JNI delegate. Example is JNIEnv.AllocObject. I think I'll need to duplicate whole JNIEnv class in order to avoid condition for each call.
Last small problem is with JNI.Dll which has the main
[DllImport("jvm.dll", CallingConvention = CallingConvention.StdCall)]
, it must be duplicated as well, because there is jvm.so on Linux.

Currently I don't hear from people that they need Mono/Linux support for jni4net. If you think you need it, please tell us the use case. I'm interested to hear why Mono support is worth of the effort. Till then I put it on ice.

jni4net version 0.8 for .NET 4.0

  • added support for CLR v 4.0
  • v40 is now loaded by default if it could be found. You could set the version explicitly with Bridge.setClrVersion()
  • #8 added BridgeSetup.AddJVMOption(string)
Download jni4net 0.8