Allow custom VM arguments for Player, Editor

It is possible now to start the ModuleManager with custom VM arguments e.g. the selection and configuration of a garbage collector. The idea is to allow the same for the Player and the Editor.

We would provide a text file with default settings, but the users could override this with custom settings.

This is customary in Java applications:


  • power users would get a way to tune the GC and other VM features to their needs
  • we could introduce -D arguments and if needed tell users to change them to a different value in case of problems, e.g. “-Dorg.vassalengine.useLegacyFeatureX=true”
  • we could put some awt/jdk arguments there e.g. “-Dawt.useSystemAAFontSettings=lcd” or “-Dsun.java2d.opengl=true”

The implementation would simply read the file line by line and in VASSAL.launch.AbstractLaunchAction.LaunchTask#doInBackground append the lines to the jvm arguments.

Sounds good?

Would you be able to make it so that dude could use the Windows LAF with the bundled JVM?

Yes, this could be solved by a parameter in this file. If the bundled “castrated” JVM is not good enough we can just bundle a regular JVM.

The jlink’ed half-JVM is no good for Vassal anyways, we can never know which parts of Java the modules are going to use. If we already bring a JVM we should be bundling a full JVM to support all kinds of custom module code.

I am also looking at the custom arguments to pass in an alternate server URL and port. (My implementation cannot reach out to It’s turning out to be a lot more tricky than it sounds.
My first thought was to use Apache Commons Configuration library. But, that was even worse.

Solution to this would be slightly different but still very similar, a .properties file where all the URLs are. We would need to extract them from the code and have the code read them from the properties file, then the users could change the properties without having to recompile anything. Something like

# vassal properties

Go for it if you think it’s worth the effort. It would make troubleshooting where we’re asking people to try different JVM flags a bit simpler.

Have a look at #149. I guess the user’s conf dir is the best place to write that file into, and I also came up with a way of cleaning up a possible mess that a user could create there.

This is merged and will be in 3.3.4.