This code in java/lang/java_props_md.c:

     /* Append CDE message and resource search path to NLSPATH and
      * XFILESEARCHPATH, in order to pick localized message for
      * FileSelectionDialog window (Bug 4173641).
      */
     setPathEnvironment("NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat");
     setPathEnvironment("XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt");

unilaterally modifies environment variables that the user expects to
see unmodified. Furthermore, it sets them to values that may be
clearly incorrect (for example, if CDE is not installed, and there
is no /usr/dt).

It is likely there is some mechanism other than the "quick hack"
of the current code to affect the search path for resources that
both respect the user settings and avoid modification of the user's
environment.

Even if those environment variables are set in the current process, they
should not be propagated to child processes. While writing my own
test cases for java.lang.ProcessBuilder, I noticed that these extra
magic environment variables were being created and had to special-case
them.

The Blackdown group was sufficiently annoyed by these that they did:

+#ifndef __linux__
     /* Append CDE message and resource search path to NLSPATH and
      * XFILESEARCHPATH, in order to pick localized message for
      * FileSelectionDialog window (Bug 4173641).
      */
     setPathEnvironment("NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat");
     setPathEnvironment("XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt");
+#endif
 
This fix is the path of least resistance. Linux users are unlikely to
be using CDE.

If we do decide to modify the environment, and the selected variables
are undefined, then they should not be unilaterally set to the values above,
but to the concatenation of the default value for
that particular operating system and the value above. This is a subtle
semantic difference.

###@###.### 2003-11-12