Question

I’m in the process of doing some Java<->.NET interop code using a native library between them, so far things are going fairly well.

However for some reason I cannot run any methods under JNIEnv.

System::String^ JNIStringToNet(JNIEnv * env, jstring js)
{
    const char *buf = env->GetStringUTFChars(js, 0); // segfault

Now I can pass variables back and forth and do all other kinds of communication, so I’m figuring I haven’t initialized this correctly or something.

I’m loading it like this:

this.Lib = (LibHandler)Native.loadLibrary(this.Name, LibHandler.class);     

(I prefer Native.loadLibrary because it seems to allow me to do more with it easier, such as class sharing between multiple libraries and unhooking and rehooking it from the JVM on the fly).

Edit:

Seriously any method:

std::cout << "Getting version:" << std::endl;
std::cout << env->GetVersion() << std::endl;

Getting version:

(segfault)

Any ideas on wht JNIEnv would segfault for every method? This should be set up by the JVM, correct?

Edit 2:

This is a Java application that is calling a C++ library that will interface with a .NET library (so it’s a CLR compiled C++ library, if that makes any difference), to limit any external factors I’m not even calling the .NET DLL but just converting strings that come in back out (or well… trying).

So for example from Java:

this.Lib = (LibHandler)Native.loadLibrary(this.Name, LibHandler.class);
this.Lib.myCPPMethod(); // Segmentation fault during this call, JVM crashes.

Curious if it was the CLR that was causing it: Disabled clr compilation and stripped everything out that was CLR related, still does it.

Edit 3:

Got it to dump:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=1596, tid=7248
#
# JRE version: 6.0_23-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  0x0000000000000000

So yeah, looks like the JVM isn’t giving me memory access for some reason.

Edit 4:

Actual call:

JNIEXPORT jstring JNICALL Query(JNIEnv * env, jobject jobj, jstring start, jstring end)
{ 
    std::cout << "Getting version:" << std::endl;
    jint j = env->GetVersion();
    return jstring("test");
}

Edit 5:

Works with System.loadLibrary:

JNIEXPORT void JNICALL Java_LibTest_T(JNIEnv *env, jobject jobj)
{ 
    std::cout << "Getting version:" << std::endl;
    jint j = env->GetVersion();
    std::cout << j << std::endl;
}

Output:

java -Djava.library.path="(dir)\lib\64" EntryPoint
Getting version:
65542

Ack! I mean some headway, but I can’t unload libraries from the JVM that are loaded in System.loadLibrary can I?

I basically need to be able to unhook these libraries from the JVM and swap them out, on top of that they all need to “share” a single class and be able to be bound to the class at runtime… which is kinda why I went with Native.loadLibrary.

Currently I do this:

Load the DLL:

this.Lib = (LibHandler)Native.loadLibrary(this.Name, LibHandler.class);

Unhook it:

this.Lib = null;
Runtime.getRuntime().gc(); // Force the JVM to drop it immediately.

Class I load them all into:

public interface LibHandler extends Library{ 
    void T();
}

Any way to work similarly with System.loadLibrary?

Edit 6:

Feel free to call me dumb, I’m using JNA, NOT JNI, which is completely different and a huge source of my problems…. is there a way to do this with JNI? Or can I get JNIEnv to register with JNA somehow? I’m guessing I can drop JNI from the C++ library and straight up use wstrings?

I’ll get back with this tomorrow.

Answer 1

Well I feel bad.

Native.loadLibrary == JNA.

System.loadLibrary == JNI.

The purpose of JNA is to not require any real knowledge of the JVM environment, so you can run native libraries as is, so instead of jstring you can use char*…