I just want to give a shout out to Marshal.GetFunctionPointerForDelegate. Oh and DllImport while I'm at it...
I've been working on one of my company's publicly released C APIs, adding new functionality. This new functionality includes adding a callback function (this C API didn't have any callbacks previously). My own local test code for the API is a C# project, which works great (I can step right into the C code from the C# wrapper code for instance). I used GetFunctionPointerForDelegate for the method I want the C code to call back into my C# code, all works great.
However our QA dept uses a Java framework for testing purposes. I was tasked to update our JNI code to support the new functionality. Ouch, my head hurts. I mean really? I think this guy said it best.
For one thing, the JNIEnv function that is supposed to return the method ID refuses to return anything other than 0 no matter how many times I checked and re-checked my code using dozens of examples from online searches.
People complain about MS all the time but then also refuse to give them credit when they do something right. And yes .Net potentially makes us "lazy" or makes us "stupid" by hiding the complexities, but I'd rather spend my time solving the real problems at the top than wasting valuable time mucking around with arcane details at the bottom.
Yes I know about JNA but I can't use that since it isn't part of our QA framework and supposedly it could be "ten times slower than hand-written JNI code".
BTW I also found out that using arrays with JNI could be slow because Java arrays (even arrays of value types) isn't blittable because the array can be non-contiguous in memory. So in your JNI code you have to call JNIEnv::GetByteArrayElements() which returns a pointer to the array, and then JNIEnv::ReleaseByteArrayElements() when you are done. What that really does is allocate a new block of contiguous memory, copies the array over to it, and then afterwards copies that back to the managed array in the release function.