Jump to: navigation, search

LateralGM uses its working directory (workdir) for a number of things. This working directory is generated at runtime using two factors: the Java current working directory (which depends on what directory you ran Java from), and the JAR file location. Because both of these locations can be volatile each time you run LateralGM, we're working on ways to refactor out this working directory dependency.

The exact code LGM uses to fetch the working directory is as follows:

workDir = new File(LGM.class.getProtectionDomain().getCodeSource().getLocation().toURI());


Immediate Uses

Extended Uses

The Plugin also uses a working directory, defined as follows:

WORKDIR = LGM.workDir.getParentFile();

Note that because of this, when using the Plugin, LateralGM and ENIGMA cannot be separated into different directories.

It is used for the following purposes:


The workdir would probably be refactored on a use-by-use basis. This is especially effective because it means we can start refactoring individual uses out immediately without worrying about how this affects other uses. All we need to consider is where do they belong, and how to access that location.

It is essential that LateralGM remain cross-platform, and it should be able to run on platforms that we haven't thought of. We should not write individual behaviors for individual platforms for two reasons:

Inside the Jar

This option has pretty much been expended - it's highly unlikely that any of the use cases would end up in here, or else they would have already been put in here.

Outside the Jar

This is the current method - the one we're trying to refactor away from.

System properties

A good way to obtain system-dependent information on a platform-independent way is to use System.getProperty. A list of available properties is here and a more extensive list here. Notably, this grants us access to the following directories:

Any of these can be turned into a "File" for Java to then navigate in, however we should be very careful about making assumptions about any directory structure from there.

Temp is also available for us, using a different method, although it is unlikely to be useful in these cases.


Properties are a great system-independent way to store preferences, settings, and properties. On Windows, this is usually the Registry, to give you an idea of what it's for. While we cannot store entire files in here, we can use this to store file and directory locations. This is a great way to allow the user to alter or install locations/files, but it doesn't provide for a default setting other than none/unset.


When in doubt, ask for directions on first run. Unfortunately, this could easily mean the user gets swamped by questions on the first run.

Properties file

We can place a properties file inside the jar which contains default paths. The user can changed these values, or, more likely, override them or change them in Settings. This method is already utilized by Libraries, as well as the external resource editors.

Personal tools