Changing the built-in search order for jvm

[sumitpendharkar]

I am bundling a jre with my product and will be installing it in a specific location. I would like to include a jvm search file to specifically for that jre. Since I set a environment variable which can be used to locate the jre, I created a jvm search file and used the PLATFORM_HINT to search for the bundled jre. Unfortunately, one of the target systems already has JRE 5.0 installed and it is in the system path. This jre is being resolved prior to my bundled jre. It either appears that the installer searches the system path prior to searching the platform_hints or my jvm file is incorrect. Here are the contents of the file --

DESC: Linux 32 bit i386 Java 1.5.0 by IBM Corporation
JVM_EXE:JRE150/jre/bin/java
PLATFORM_HINT:
DB2TOOLS
/:
PATH_HINT:
/:
JVM_PROPERTIES:
java.vendor=IBM...
java.version=1.5.0
/:
CLASSPATH: "-cp "
CLASSPATH_SEPARATOR: :
SYSTEM: "-D"
SYSTEM_SEPARATOR: =
INIT_HEAP_SIZE: "-Xms"
MAX_HEAP_SIZE: "-Xmx"

We need to ship pretty soon, so any help will be appreciated. Thx.

[mmonahan]

I'm hitting the same problem on AIX. I only want to use our bundled 1.4.2 JVM. I tried the following two jvm files, but the first failed to start and the second still used the system installed jvm:

Failed to start:
DESC: AIX Java 1.4.2 by IBM
JVM_EXE: bin/java
CLASSPATH: "-cp "
CLASSPATH_SEPARATOR: :
SYSTEM: -D
SYSTEM_SEPARATOR: =
JVM_PROPERTIES:
"java.vendor=IBM..."
"java.version=1.4.2..."
/:
SET_ENV_FOR_WIZARD:
JAVA2D_USEAWTFONTS=0
/:
AIX_32BIT_ENV_VARS:
LDR_CNTRL=MAXDATA=0x40000000
/:
AIX_32BIT_ENV_VARS_FOR_PRODLAUNCHER:
0

/:
AIX_64BIT_ENV_VARS:
LDR_CNTRL=MAXDATA=0x40000000
/:
AIX_64BIT_ENV_VARS_FOR_PRODLAUNCHER:
0

/:
VERBOSE: -verbose
VERBOSE_GC: -verbose:gc
VERBOSE_CLASS: -verbose:class
VERBOSE_JNI: -verbose:jni
VERSION: -version
BOOT_CLASSPATH: -Xbootclasspath:
NO_CLASS_GC: -Xnoclassgc
INIT_JAVA_HEAP: -Xms
MAX_JAVA_HEAP: -Xmx
REDUCE_OS_SIGNALS: -Xrs
CHECK_JNI: -Xcheck:jni
RUNHPROF_HELP: -Xrunhprof:help
RUNHPROF_OPTION: -Xrunhprof
DEBUG: -Xdebug



Uses system jre:

DESC: AIX Java 1.4.2 by IBM
JVM_EXE: bin/java
CLASSPATH: "-cp "
CLASSPATH_SEPARATOR: :
SYSTEM: -D
SYSTEM_SEPARATOR: =
JVM_PROPERTIES:
"java.vendor=IBM..."
"java.version=1.4.2..."
/:
SET_ENV_FOR_WIZARD:
JAVA2D_USEAWTFONTS=0
/:
AIX_32BIT_ENV_VARS:
LDR_CNTRL=MAXDATA=0x40000000
/:
AIX_32BIT_ENV_VARS_FOR_PRODLAUNCHER:
0

/:
AIX_64BIT_ENV_VARS:
LDR_CNTRL=MAXDATA=0x40000000
/:
AIX_64BIT_ENV_VARS_FOR_PRODLAUNCHER:
0

/:
PLATFORM_HINT:
/:
PATH_HINT:
/:
VERBOSE: -verbose
VERBOSE_GC: -verbose:gc
VERBOSE_CLASS: -verbose:class
VERBOSE_JNI: -verbose:jni
VERSION: -version
BOOT_CLASSPATH: -Xbootclasspath:
NO_CLASS_GC: -Xnoclassgc
INIT_JAVA_HEAP: -Xms
MAX_JAVA_HEAP: -Xmx
REDUCE_OS_SIGNALS: -Xrs
CHECK_JNI: -Xcheck:jni
RUNHPROF_HELP: -Xrunhprof:help
RUNHPROF_OPTION: -Xrunhprof
DEBUG: -Xdebug
...................................................................................

We've been burned by jre's that are corrupted, and we really want to force them to use ours... what am I missing?

[enanrum]

I only use bundled JVM's because of many issues searching for JVM's - one that was killing me for a long time was when systems have a linked java in /bin as in /bin/java! ISMP doesn't follow that link in bin and thinks its in the bin directory of the JVM and looks for the java's lib directory on the same level (/lib) and doesn't the actual java libraries and cancels with a JVM not found error!

Anyway - all you have to do is just remove any Search Routines for the JVMS and only have the Bundled JVM included and it will always use that JVM!

[mmonahan]

Apparently, InstallShield changed the code at some point for Unix so it will always check the path before it checks the search hints. This was supposed to be a performance improvement. But, as a consequence, even if I removed all search instructions, it was still finding the JVM in the system path.

I was able to get around the problem by putting SKIP_PATH_SEARCH:true in my jvm file. However, I'm not sure this value is supported in the GA version of 11.5, since I know the scriptlauncherstub.sh files I have were updated in a private fix pack I applied for different reasons.