There are some usage scenarios in which it would be convenient to tunnel options to javac via an environment variable.  This could be used to either provide directly some default options, or to provide them indirectly, in an @argfile.

By analogy with the existing undocumented but reasonably well-known option _JAVA_OPTIONS for tunnelling values to the VM, it is proposed to support a like-named option _JAVAC_OPTIONS.
 
The leading _ is retained to indicate this is less "public" than a name like JAVAC_OPTIONS might indicate.

If the env variable is set when javac is invoked from the command line, the value will be split into words, and the words used to prefix the array of arguments specified directly as args on the command line.
 
There is no special handling to "merge" duplicate options specified in the env variable and on the command line. The behavior is essentially as though javac had been invoked with the following command:
    javac ${_JAVAC_OPTIONS} options files
 
The implication is that the existing, standard rules of "last one wins" etc will apply.
 
It is also implied that the environment variable will be expanded and prefixed to the explicit arg list before @argfile expansion takes place. In other words, the env variable may contain use of @argfiles.
 
The env variable will also be taken into account by the underlying equivalent public API methods, com.sun.tools.javac.Main::compile and javax.tools.JavaCompiler::run
 
It is deliberate and intentional that the environment variable is _not_ taken into account by the javax.tools.JavaCompiler::getTask method.  Environment variables are a dangerous/expert feature, and there is no way to modify/override the values in a running process. If a client wants to take _JAVAC_OPTIONS into account when calling getTask, it is reasonably easy to get the value, split it into words, and prepend the words to the list of options passed to JavaCompiler::getTask.