Application with an embedded JVM can set enviroment variables

THE PROBLEM:

Consider an app MyApp.exe statically linked with javai.dll. The behavior
of javai depends on many environment variables, for example:

    win32/java/runtime/properties_md.c: if ((v = getenv("JAVA_HOME")) != 0) {
    win32/java/runtime/properties_md.c: v = getenv("CLASSPATH");
    win32/java/runtime/properties_md.c: if ((v = getenv("USER")) == 0) {
    win32/java/runtime/properties_md.c: if ((v = getenv("HOME")) != 0) {
    win32/java/runtime/properties_md.c: char *drive = getenv("HOMEDRIVE");
    win32/java/runtime/properties_md.c: char *path = getenv("HOMEPATH");
    win32/java/runtime/properties_md.c: if ((v = getenv("JAVA_COMPILER")) != 0) {

Now, the environment variables seen by javai are those existing at the
time javai.dll is loaded into virtual memory, that is, when MyApp.exe
is loaded. Thus, MyApp.exe has no way of changing the environment
variables seen by javai.dll!

One might ask, "What's wrong with forcing the user to set environment
variables?" Well, (1) the user should not even have to know that Java
is running! --- use of Java should be encapsulatable, (2) The app
might want to use the Windows Registry for determining behavior, (3)
The app might want to override environment variables, (4) Apps started
from icons are going to see only the top-most set of environment
variables, thus making all applications share the JAVA_HOME,
CLASSPATH, etc. (Symantec stumbled on this in their release of
Cafe. Installing Cafe 1.0 changed PATH and CLASSPATH, thus breaking
Sun's JDK.)

WORKAROUND:

Structure MyApp as a small .exe file that sets environment variables
and then dynamically (via LoadLibrary) links AppGuts.dll which has
been statically linked (via export library) with javai.dll. The
environment variables seen by javai are thus those set by MyApp.exe
before AppGuts.dll is loaded. In this way, the application can control
the environment variables seen by javai.dll. Yukk.

PROPOSAL:

In Win32 (at the least) arguments to JNI_CreateJavaVM should be used,
when present, for determining Java behavior in preference to
getenv(). Then, javai.dll could be statically linked to an .exe file
without the above effects.

Jeff Finger
Advanced Technology Group
Adobe Systems Incorporated