The startup scripts of tomcat will run a setenv.sh file if it exists. Create it (in the tomcat bin/ ) directory and write your customization there, e.g. that file can just contain the line:

export JAVA_OPTS="-Xms756m -Xmx756m -Xss128m -Xmn512m"

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.

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.

JAVA_OPTS is the standard environment variable that some servers and other java apps append to the call that executes the java command.

For example in tomcat if you define JAVA_OPTS='-Xmx1024m', the startup script will execute java org.apache.tomcat.Servert -Xmx1024m

If you are running in Linux/OSX, you can set the JAVA_OPTS, right before you call the startup script by doing

JAVA_OPTS='-Djava.awt.headless=true'

This will only last as long as the console is open. To make it more permanent you can add it to your ~/.profile or ~/.bashrc file.

Hmm, deleted the whole file and recreated it, and now it works..... Now using this style

export JAVA_OPTS="$JAVA_OPTS\
 -server\
 -Xms704m\
 -Xmx704m\
 -XX:OnOutOfMemoryError=/usr/share/scripts/on_server_crash.sh\
 -XX:+HeapDumpOnOutOfMemoryError\
 -XX:HeapDumpPath=/var/log/tomcat7\
 -XX:MaxPermSize=128m\
 -XX:MaxNewSize=256m\
 -XX:NewSize=256m\
 -XX:SurvivorRatio=12\
 -XX:MaxTenuringThreshold=0\
 -XX:+UseConcMarkSweepGC\
 -XX:+CMSIncrementalMode\
 -XX:+CMSIncrementalPacing\
 -XX:+CMSClassUnloadingEnabled\
 -XX:+CMSPermGenSweepingEnabled\
 -XX:+DisableExplicitGC\
 -XX:+UseParNewGC\
 -XX:+UseTLAB\
 -Djava.awt.headless=true\
 -javaagent:$NR_JAR\
 -Dnewrelic. environment=production"

You can use java/tomcat security manager and policy files to give or not to give permission to running code to do reflection or other sensitive operations (io/file access, etc.).

See "Security Restrictions" on http://docs.oracle.com/javase/tutorial/reflect/ and google for "tomcat security manager" or "java security manager".