Launching a 64 bit jvm from a 32 bit jvm

Question

I want to launch a 64 bit jvm from a 32 bit jvm. The current application works like this
1) The parent jvm A allows users to launch a child jvm B. Child jvm B inherits A's libraries (LD_LIBRARY_PATH) and also A's classpath entries.
2) User can specify his/her own libraries that are to be passed to B (child jvm). These entries are prepended to the inherited entries (A.LD_LIBRARY_PATH).
3) User can specify his/her own classpath entries that are to be added to B. These entries are appended to the inherited entries (A.classapth).
The whole idea behind making the child jvm configurable is that the user can specify a suitable jvm for the child. But optionally the user might specify a different java home (pointing to a 64bit jre/jdk).
Questions :
1) Would simply changing the java for the child suffice? That is instead of
java -classpath=<inherited-entries:specified-entries> abc
we do
-user-specified-java -classpath=<inherited-entries:specified-entries> abc
I have seen that the jvm uses the java.home from the java provided while launching the jvm. Example
$java -version
1.5
$java abc
// will use default java's home as java home internally
$/usr/lib/java-64/jdk/bin/java -version
1.5 64bit
$/usr/lib/java-64/jdk/binjava abc
// will use /usr/lib/java-64/jdk as java home internally
2) How will the classpath entries and libraries interact/interfere with the newly spawned jvm?
Here if the user specifies new libraries for 64 bit jvm, how will they interact/interfere with the 32bit libs.
3) What about native(esp jni) libraries?
Bigger picture :
If A is running sun java jdk1.5_a (32bit) and user can specify B as
1) sun jdk 1.x_y (32bit) such that x_y != 5_a
2) sun jdk 64 bit
3) any other 32 bit java implementation (ibm, jrocket ...)
4) any other 64 bit java implementation (ibm, jrocket ...)

Answer 1

jschell wrote:
Questions :
1) Would simply changing the java for the child suffice? That is instead of
java -classpath=<inherited-entries:specified-entries> abc
we do
-user-specified-java -classpath=<inherited-entries:specified-entries> abc
You cannot do it without creating a new process.
ProcessBuilder/Runtime.exec() create a new process. The new process can do anything.
You can set the environment using either.
Yes. The process B will be spawned either using ProcessBuilder or using Runtime. The question still remains,
Q: If I have a classpath defined already for a particular java implementation and the LD_LIBRARY path is all set, what will be effect of changing the default java.
Example :
If my classpath and LD_LIBRARY_PATH is set to use/work-with /usr/lib/javaA/ then
"/usr/lib/javaA/jre/bin/java -classpath $classpath abc" will work smoothly
But what will happen if I do classpath=$classpath:$new-javaB-classpath-entries and LD_LIBRARY_PATH=$LD_LIBRARY_PATH_FOR_B:$LD_LIBRARY_PATH and
"/usr/lib/javaB/jre/bin/java -classpath $classpath abc"
>
2) How will the classpath entries and libraries interact/interfere with the newly spawned jvm?
Here if the user specifies new libraries for 64 bit jvm, how will they interact/interfere with the 32bit libs.
3) What about native(esp jni) libraries?
New process = new environment.
If there is a problem it is because of how you set it up or how they are used in the first place.I am more interested in the if. My question is can it happen and if yes whats the explanation and how to solve it.
>
As an example if an app needs a 64 bit library and there is only a 32 bit library then what happens depends entirely on the app that needs the 64 bit library. That question would be the same if you attempted to run the application from a console window.So here is another way of looking at it. Imagine you want to kick off a 64 bit java app from your console. Assume that you can only prepend to classpath. Also you can append to LD path. Now you have provided all that is needed for the app to run. But under the classpath constraints, what will be the behaviour?