How to Provide Native Methods in an Executable?

Question

Hey there,
I'm writing a native Java launcher as a replacement for java.exe (or eclipse.exe). So far I'm only on Windows NT x64. Things work pretty well: My native executable launches the JVM using the Invocation API and calls a static `main' method.
Now I thought it was a good idea if my executable could provide the implementations of a few native methods so the `jvm.dll' can communicate with the executable that it was loaded by. This would free me from having to locate and load a shared library at runtime. I expected this to "just work," but alas, it didn't. Providing a simple native method such as
JNIEXPORT jboolean JNICALL
Java_com_phrood_kourou_Kourou_available0(JNIEnv* env, jclass cls) {
return JNI_TRUE;
in the executable and calling it from Java through JNI, I get an `UnsatisfiedLinkError'. Why is that so? Both the executable and the DLL live in the same process, so shouldn't the C function be found without further concern?
Then I came up with the somewhat experimental idea and just loaded the EXE file from Java by `System.load(pathToExe)'. I never expected this to work, but---it did!
That's good news, of course. Only I'm afraid that's a lot more memory-consuming than it needs to be. My EXE file has some 200 KB and counting, and I only need I a handful of small native-method implementations. I could write a DLL, of course, but I'd like to do without an extra file and an extra project to set up and maintain.
So, my question is: Why do I have to load the EXE into the same process a second time? Is there a more elegant solution?
Regards,
-- Phil

Answer 1

It doesn't work anyway. Although I can load my EXE as a DLL, the newly-loaded image has its own address space, so I cannot use that to call back the EXE.
I think I can acomplish what I need without a DLL altogether. Hopefully.
I want the usage of my executable to be as simple as using `java.exe'. Clients should just write a configuration file, rename and start or double-click the EXE and that's it. An MSI would be pointless here, since the usage of the launcher is completely generic.
More importantly, maintaining cross-platforms C++ projects with Eclipse CDT is possible but a bit of a hassle. I already have two projects: one for the EXE and one for the Java companion Jar. Creating a new DLL project would require me to maintain 3 Eclipse build configurations for Windows, Linux, and Mac; and even another three should I support the x86 architecture. I'd be happy if I could do without.
What strikes me is that you folks try to teach me what I should do or not do, even call my problem a "nonproblem," rather than just help me out and try to answer my questions. None of the answers here were helpful to me, but I think I figured it out.
Nonetheless, thanks for taking the time to read and answer.