On Fri, Jul 8, 2016 at 6:58 AM, Russel Winder <[email protected]> wrote:
> On Fri, 2016-07-08 at 14:34 +0100, Russel Winder wrote: > > Turns out it is not a Groovy or Gradle thing, it seems the Java > > executable doesn't like the options it advertises it responds to. > > > > > > (export _JAVA_OPTIONS="-addmods java.xml.bind" > > > > && /home/users/russel/lib.Linux.x86_64/JDK9/bin/java -version) > > Unrecognized option: -addmods > > Error: Could not create the Java Virtual Machine. > > Error: A fatal exception has occurred. Program will exit. > > > Anyone know the difference between _JAVA_OPTIONS and JAVA_OPTIONS? > > I believe _JAVA_OPTIONS can be used to pass default options to the JVM and takes precedence over command line arguments you would normally want to pass to java/javac and other jvm tools. There's also JAVA_TOOL_OPTIONS but it is lowest in priority and _JAVA_OPTIONS and command line parameters are used first in that order. I'm not aware of a JAVA_OPTIONS. There is a lot of use of JAVA_OPTS but that is not read by any of the JVM tools to my knowledge, unlike the _JAVA_OPTIONS and JAVA_TOOL_OPTIONS which there exists code in hotspot to read those env vars. JAVA_OPTS seems to be just a conventional name used by many scripts use it when they call the java executible (i.e., java %JAVA_OPTS% ....).
