You have pretty much nailed it except that these options are picked up even if you start JVM in-process via a library call.
The fact that _JAVA_OPTIONS is not documented suggests that it is not recommended to use this variable, and I've actually seen people abuse it by setting it in their ~/.bashrc. However, if you want to get to the bottom of this problem, you can check the source of Oracle HotSpot VM (e.g. in OpenJDK7).
You should also remember that there is no guarantee other VMs have or will continue to have support for undocumented variables.
UPDATE 2015-08-04: To save five minutes for folks coming from search engines, _JAVA_OPTIONS trumps command-line arguments, which in turn trump JAVA_TOOL_OPTIONS.
You have pretty much nailed it except that these options are picked up even if you start JVM in-process via a library call.
The fact that _JAVA_OPTIONS is not documented suggests that it is not recommended to use this variable, and I've actually seen people abuse it by setting it in their ~/.bashrc. However, if you want to get to the bottom of this problem, you can check the source of Oracle HotSpot VM (e.g. in OpenJDK7).
You should also remember that there is no guarantee other VMs have or will continue to have support for undocumented variables.
UPDATE 2015-08-04: To save five minutes for folks coming from search engines, _JAVA_OPTIONS trumps command-line arguments, which in turn trump JAVA_TOOL_OPTIONS.
There is one more difference: _JAVA_OPTIONS is Oracle specific. IBM JVM is using IBM_JAVA_OPTIONS instead. This was probably done to be able to define machine-specific options without collisions. JAVA_TOOL_OPTIONS is recognized by all VMs.
Videos
JDK_JAVA_OPTIONSis only picked up by thejavalauncher, so use it for options that you only want to apply (or only make sense for) the java startup command. This variable is also new on JDK 9+, and will be ignored by earlier JDK versions. Hence, it's useful when migrating from older versions to 9+.JAVA_TOOL_OPTIONSis picked up also by other java tools likejarandjavacso it should be used for flags that you want to apply (and are valid) to all those java tools.
The functional difference between the two variables is explained by @gjoranv's answer.
The differences in the output I think stem from the following:
The two variables seem to be implemented in different points in the launching process.
The
JDK_JAVA_OPTIONSdocumentation says:In order to mitigate potential misuse of JDK_JAVA_OPTIONS behavior, options that specify the main class (such as -jar) or cause the java launcher to exit without executing the main class (such as -h) are disallowed in the environment variable. If any of these options appear in the environment variable, the launcher will abort with an error message.
This line:
Error: Cannot specify main class in environment variable JDK_JAVA_OPTIONSis the error message that warns the user of a potential attempt to do mayhem via that variable.
I think that
JDK_JAVA_OPTIONStakes precedence, in part for the same reason.
I tried setting this variable in my windows environment with Java 7 and doing java -version it gives me it set this variable , as shown as follows
C:\Users\ajduke>set JAVA_TOOL_OPTIONS=-Djava.net.preferIPv4Stack=true -Dfile.e
ncoding=UTF8
C:\Users\ajduke>java -version
Picked up JAVA_TOOL_OPTIONS: -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF
8
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b145)
Java HotSpot(TM) Client VM (build 21.0-b15, mixed mode, sharing)
In case only the first argument is picked up: DON'T USE QUOTES! Just the arguments:
set JAVA_TOOL_OPTIONS=-Xms128m -Xmx512m
In my case (Windows), only the first argument was picked up and reported to be invalid, since I used
set JAVA_TOOL_OPTIONS="-Xms128m -Xmx512m"
and starting any java app results in:
Picked up JAVA_TOOL_OPTIONS: "-Xms128m -Xmx512m"
Invalid initial heap size: -Xms128m -Xmx512m
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.