I've noticed that the environment in Java on Windows (as obtained by a System.getenv() call) includes some variables that don't exist in the real environment. These begin with and equals-sign and include "=ExitCode" which maps to the exit code of the process that ran just before this java invokation; and the default directories of various drive letters, such as "=C:", "=D:". This seems to be the case with all of Sun's Java versions, running on all Windows versions. Is this documented anywhere, or is it purely for Sun's internal only?
Edit Here's a simple example application to show what I mean. Compile and run this on the command line:
import java.util.Map;
class ShowEnv {
public static void main(String[] args) {
for (Map.Entry v : System.getenv().entrySet())
System.out.printf("%-23s= %.54s%n", v.getKey(), v.getValue());
}
}
Then compare the variables with the SET command (from cmd.exe) or with similar command-line program written in C. You'll find the variables beginning with = don't exist in those:
=ExitCode = 00000000 =:: = ::\ =C: = C:\Temp
These variables are obviously added during execution of the JVM.
System variables that start in equal sign are real. What you observe is not Java adding more environment variables; it is SET
command hiding some of the variables.
Windows prohibits the use of equal sign in names of environment variables that users can set, thus reserving variables with =
in them for internal use. These variables can be retrieved through windows APIs, e.g. GetEnvironmentStringsW
. Java library does not filter this list, so the special variables become available to your code. SET
command of Windows, on the other hand, filters them out, creating a discrepancy.
According to this answer, these "magic" variables are there for backward compatibility with ms-dos directory handling, so you can safely ignore them.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments