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)

You can use _JAVA_OPTIONS to pass options to any JVM process started on your system.

For example,

set _JAVA_OPTIONS=-Dsun.java2d.noddraw=true

When a JVM starts, it parses the value of _JAVA_OPTIONS as if the parameters were at the command line of java. You can see the passed parameters via JVisualVM.

For more information, read the blog post: What I discovered while trying to pass Default JVM Parameters

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.