3

I am running Windows 7 64bit, and Java 1.8. When I try to call JNI_CreateJavaVM the program exits. It does not "crash", is actually calls exit(). (!!)

I have already researched, and found these other discussions:

Invoking Java from C++: how to catch/detect a fatal JVM error?

JNI_CreateJavaVM() terminates with exit code 1

They do not solve the problem.

So, if the environment isn't setup right, the program will just disappear. I am tasked with creating an app that must use a Java lib to execute. And if the users environment (which I have no control over) isn't set right, or is modified later, the program simply "goes away", where I have no ability to do any defensive coding!

What type of mental disorder was present when some Oracle guy thought this was a good idea??

Java installs itself and modifies the path with the the directory C:\PROGRAMDATA\ORACLE\JAVA\JAVAPATH... And in there are a bunch of shortcuts to the current version of Java ("C:\Program Files (x86)\Java\jre1.8.0_31\bin" in my case). If I have to modify the path to also point to the location of the JVM dll (which conveniently is NOT in the same location, but in a sub-directory) and later something updates Java and changes those shortcuts, the path will still point to the old DLL.

Has anyone found a way to accomplish this? I mean robustly? In other words, while still being a good programmer? Because the JNI/JVM environment is definitely trying to prevent you from doing so.

Community
  • 1
  • 1
SpacemanScott
  • 953
  • 9
  • 21
  • Not sure what you're asking but regarding jvm.dll: you don't need any of the stuff elsewhere. jvm.dll and an entry in PATH to point to the directory it's in is everything you need. Get its location from the registry and you're good. (Also I've seen the exit behavior you describe. In our case it was because of a faulty class path. We tried to initialize the system class loader to something the VM couldn't find) – user2543253 Mar 31 '15 at 17:26
  • Not sure what you are talking about... I moved the DLL to my local folder, and the thing still exits. I moved the DLL to a location that is in the path, and the thing still exits. So clearly just having the DLL in the path is *not* the solution. The only way to make it work is add a path, and that may or may not be the correct subfolder because the shortcuts hidden in the "programdata\..." location may point to a different engine depending on what the user has installed. This is weak, it is poor design. And the concept that the DLL just exits is downright bad programming practice. – SpacemanScott Apr 02 '15 at 03:47
  • So I am asking: How do you correctly refer to the JAVA installation? if you have to modify the path, and it may not point to the JAVA folder that is referred to by the "ProgramData" shortcuts. – SpacemanScott Apr 02 '15 at 03:50
  • The exit has nothing to do with where the Java installation is. Find jvm.dll in the registry (*don't* move the DLL), set the PATH to it's directory so it can find the other DLLs, Java installation part is done (ignore those shortcuts). It exits (presumably) because it doesn't like your startup parameters (except if you messed up your Java installation by moving too much stuff around. Try with a clean install and without parameters at first) – user2543253 Apr 02 '15 at 09:28
  • I know the exit has nothing to do with the JVN. It is a major flaw in the DLL.
    As for why it fails, all I did was move the DLL to my local folder. But apparently, it requires that there be other things relative to the location of the DLL.
    So here;s another disorder in the way I see it working:
    Pretend I wish to use a JVM that is in "jre1.8.0_31". But someone updated to jre1.10.0_xx. So the system is updated to use the new runtime, and the path is changed via the C:\PROGRAMDATA\ORACLE\JAVA\JAVAPATH shortcut. The JVM that I *want* to use is no longer in the path.     – SpacemanScott Apr 12 '15 at 23:14
  • So it's broken, and not anything I could control. – SpacemanScott Apr 12 '15 at 23:14
  • Regarding your example with the two versions of jre: you really don't care. Again: you find the location of the DLL in the registry, and if that wasn't clear before: *at runtime* then you adjust your PATH *in the running process* to include the directory where the other DLLs are in. Then you call LoadLibrary & GetProcAddress. Really no problem there. And you don't move any files. Because most software stops working correctly if you start moving files to where they don't belong. – user2543253 Apr 13 '15 at 09:51

0 Answers0