JNI (Java from C) -- multiple JREs installed, need to use non-default one
Hello,
I don't know how many Google/forum searches I must have tried -- I can't seem to find a solution to my problem.
I am calling Java from C. We have two types of environments:
(1) 1.3/1.4 mix, and
(2) 1.4 only.
The mixed environments are configured to use 1.3 by default. This configuration will not be changed. The original developer's code needs backported to the mixed environment, but it has been discovered that his Java code is not 1.3-compatible.
Since the code is not compatible with 1.3, I need a way to bypass the default JRE setting and get JNI to start a 1.4 JVM. Is there a way to do this?
Thank you for your help.
[683 byte] By [
davebba] at [2007-11-27 10:17:55]
Use the full path to specify the java.exe that you want to execute. If you use just "java.exe", then you execute the default program (whatever that is, and it can vary by machine and os.)
Hi,
The site claims my 'davebb' login suddenly no longer exists, so I've created another account. (I noticed that just yesterday a lot of *.sun.com pages were redirecting to a "we're doing maintenance" page, so maybe something got fouled up).
Anyway, I think you misunderstand what I am trying to accomplish. Or perhaps the misunderstanding is mine. I have an executable, written in C, which uses JNI to start a JVM. The executable is launched from the command line, after which it's up to that application to start a JVM. It's not like I am at a command line with a jar and am manually specifying which JRE to use. (If I were, I would do exactly what you suggested).
Unless there's something I don't know about JNI (there's a lot I don't know, but I've done Java-to-C before, just not the other way around, so JNI's not totally foreign to me), I don't understand how I could do what you've suggested.
*bump*
Hmm, my account works again.
This got pushed down to page 11, which means it would never be seen again (2 views in about 22 hours). Sorry if this is discourteous, but this is a pressing issue. Anyone have an idea?
> Since the code is not compatible with 1.3, I need a
> way to bypass the default JRE setting and get JNI to
> start a 1.4 JVM. Is there a way to do this?
I doubt it.
Bug, it has to find the jni.dll so you could just insure that that is the only dll on the box and try it but I suspect it just won't start.
Note that even if it does you must fully regression test the code because there are changes in the api.
Here I found a post where someone was reading the windows registry to find the path to jvm.dll, loading that library and then creating the VM with exactly that VM:
http://forum.java.sun.com/thread.jspa?threadID=5124559&messageID=9439662
You could perhaps reuse some of these ideas and look for the path to the 1.4 VM in the registry?
My apologies -- I forgot to mention that this is an AIX system. I didn't figure it to be important because I was hoping to hear from someone that I could just use some JNI functionality which I do not know about.
I was hoping I could get it to populate an array of "AvailableJRE" structures or something, and that I could search the array for AvailableJRE.version == 1.4. I would then pass the relevant info into JNI_CreateJavaVM. It's starting to look as if there is no such built-in functionality, and that is truly disappointing.
This morning I actually tried something similar to what was being suggested in that thread. I have a functioning workaround in place which prepends PATH, CLASSPATH, etc with 1.4 paths right before JNI is invoked (setenv calls in C), then they are restored to their original values after the JNI stuff is done. That's ugly...
> I was hoping I could get it to populate an array of
> "AvailableJRE" structures or something, and that I
> could search the array for AvailableJRE.version ==
> 1.4. I would then pass the relevant info into
> JNI_CreateJavaVM. It's starting to look as if there
> is no such built-in functionality, and that is truly
> disappointing.
>
Huh?
If you can modify the code then the solution is to modify the code.
> Huh?
Huh?
> If you can modify the code then the solution is to
> modify the code.
My "solution" is a kludge. It attempts to compensate for what I thus far believe to be an apparent lack of functionality. I believe the functionality I described should exist in JNI so that little jewels like my "solution" are not needed. What I am doing is improper. Therefore, I respectfully disagree with you.
> My "solution" is a kludge. It attempts to compensate
> for what I thus far believe to be an apparent lack of
> functionality. I believe the functionality I
> described should exist in JNI so that little jewels
> like my "solution" are not needed. What I am doing
> is improper. Therefore, I respectfully disagree with
> you.
Except that your OP suggested that if you could replace it with 1.4 then that would be suitable solution.
So if that is a suitable solution and you can in fact modify the JNI code then that is a solution that meets all of your needs.
Regardless however you will note that the "The Java Native Interface" book in chapter 7 provides a specific section which
1. Specifically points out why you can't depend on a generic VM loading mechanism
2. Provides a specific mechanism which is OS/Platform specific, for doing runtime loading of the VM presuming certain constraints are followed.
