Using Processing 1.0.9, I tried compiling the command-line version of Processing
using processing.app.Commander, but even after compilation I was still getting errors
complaining that the X11 DISPLAY variable had not been set.

The error seemed to be in line 106 of Commander.java, which reads:

int platformIndex = PApplet.platform; // default to this platform

It seems that the only reference to PApplet in the class attempts to trigger the
creation of a PApplet, requiring that X11 be available.

Removing the PApplet.platform reference and hard-coding an integer resolved the
problem and allowed me to run the command line sucessfully.

Scratch the above. I was able to get a working commandline by doing the following:

Commenting out line 166 of processing.app.Preferences:
// other things that have to be set explicitly for the defaults
// setColor("run.window.bgcolor", SystemColor.control);

Nullifying line 228 of processing.core.PApplet:
static public final int MENU_SHORTCUT = 0;
// Toolkit.getDefaultToolkit().getMenuShortcutKeyMask();

Actually I believe you are right that any call to PApplet static methods causes headless
exceptions. For a project I started last year and will be releasing in the nearish future I
needed a version of Processing running on an ubuntu server that could export applets through
the Commander class.

The main causes (95%~) of headless exceptions were PApplet static method calls, with a few
other things causing headless exceptions.

Something I noticed was that all the calls to PApplet were utility methods for opening files,
writing files, reading files, regex matching etc. Nothing specific to PApplet was required. The
ideal solution I think would be to make a processing.app.Utility class which could house these
methods for use by processing.app classes instead of using the processing.core.PApplet.

Unfortunately, I didn't think of that when I started getting Processing working from cli in a
headless environment (I didn't know the problem at the time) so I ended up with a horrific
mess of copied methods from PApplet in the classes that called them.. so I don't think that's
going to be useful to anyone as a patch.

There were a few other cases which caused headless exceptions, unfortunately I wasn't
thorough in documenting these and have forgotten what they were, but duplicating the
functionality of these utility methods outside of PApplet I believe would be a good start.

- James

PS: If this should be its own bug report/feature request please let me know.

Probably a better solution will simply be to use a fake AWT implementation
that doesn't require X11. Otherwise we're talking about significant
refactoring work for Unix systems (less than 2-3% of our users) who are
trying to run from the CLI (a tiny percentage of that 2-3%).