You know how to set the variable in a shell, but for the record you can write:
export _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on'
and all programs you start from this shell session after that will have the variable set.
If you want it to be set for every shell you start afterwards, add that line to ~/.profile as well. In that case it will apply to all future shells you start, but not any that are currently running.
.profile will generally work for the GUI as well, but that can be broken by system configuration and how you start things up. This is per-user configuration only.
If you want it set for every user all the time, you can add an assignment to /etc/environment. The format is a little different there: just KEY=VAL on separate lines, with no required quoting and none of anything else.
_JAVA_OPTIONS=-Dawt.useSystemAAFontSettings=on
This is parsed by the pam_env module. There is a per-user ~/.pam_environment file as well, which has the same effect for just the one user. These both require logging out and back in for the change to take effect. The variables will be set for every future login session, both at the console and in X.
Similarly, you can make a file in /etc/profile.d with an export statement in it and it will be loaded into every future session by any user. There will likely be some pre-existing files there to model it on, but just the export line above will be fine.
Alternatively, you can add the export statement in ~/.xinitrc (if you use startx), ~/.xsession, or ~/.xprofile. KDE also supports a directory ~/.kde/env that can contain as many shell files as you want, which contain export statements as above. I would probably prefer one of the other approaches.
How do I set Java's min and max heap size through environment variables? - Stack Overflow
java - Information about _JAVA_OPTIONS - Stack Overflow
java opts - how to set JAVA_OPTS for Tomcat in Windows? - Stack Overflow
java - Setting JAVA_OPTS in windows using command prompt - Stack Overflow
Videos
You can't do it using environment variables directly. You need to use the set of "non standard" options that are passed to the java command. Run: java -X for details. The options you're looking for are -Xmx and -Xms (this is "initial" heap size, so probably what you're looking for.)
Some products like Ant or Tomcat might come with a batch script that looks for the JAVA_OPTS environment variable, but it's not part of the Java runtime. If you are using one of those products, you may be able to set the variable like:
Copyset JAVA_OPTS="-Xms128m -Xmx256m"
You can also take this approach with your own command line like:
Copyset JAVA_OPTS="-Xms128m -Xmx256m"
java ${JAVA_OPTS} MyClass
If you want any java process, not just ant or Tomcat, to pick up options like -Xmx use the environment variable _JAVA_OPTIONS.
In bash: export _JAVA_OPTIONS="-Xmx1g"
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
And according to https://bugs.openjdk.java.net/browse/JDK-4971166 undocumented Hotspot-specific _JAVA_OPTIONS was superseded by JAVA_TOOL_OPTIONS that is included in standard JVMTI specification, does better handling of quoted spaces and should be always preferred.
Since JDK 9+ there's also JDK_JAVA_OPTIONS as the preferred replacement, see What is the difference between JDK_JAVA_OPTIONS and JAVA_TOOL_OPTIONS when using Java 11?
on windows you have to set the variable like:
set JAVA_OPTS = “-Xdebug , server=y”
and use it this way
java %JAVA_OPTS% –cp .Server
Windows uses "%JAVA_OPTS% rather than "$JAVA_OPTS" which is UNIX/LINUX. You can check if the environment is updated with JAVA_OPTS by echoing that: echo %JAVA_OPTS%.
I just spent a good chunk of time debugging an issue because a user had set _JAVA_OPTIONS to use a low Xmx value in their environment variables. This was an application created with jpackage, which should be fully standalone. It even had a custom Xmx value set in the JVM arguments for the image but the environment variable overwrote the value!
Isn't this like a huge design flaw? I can just do echo "_JAVA_OPTIONS=<Wacky VM options>" >> ~/.bashrc or setx to break literally every Java application on the system? (Edit: Maybe the initial security focus was wrong, changed it a bit to focus more on the design issues)
Who even thought that this would be a good idea with no option to disable this behavior?