The problem with your approach stems from the primary reason enum
s are so good as singletons.
Let me suggest an analogy with Schrödinger's cat thought experiment. An enum
is like the state of the cat, it is instantly completely known when the box is opened and stays that way forever. This is guaranteed by the nature of an enum
, i.e. however many people look in the box it is only the first viewer of the state of the cat that actually causes the cat to have a state. Everyone else sees an exact copy of that moment.
You therefore have two ways to install outside data into the final state of the enum
. You can either guarantee to be the one that opens the box first or - and here I stretch the analogy a little - you teach the cat to quickly reach out and grab it's state when the box first opens.
Option 1 is as complex as achieving the singleton. Being absolutely sure you are first is well nigh impossible.
So option 2 could look something like:
public enum Singleton {
INSTANCE;
final String fromLocation;
final String toLocation;
private Singleton () {
// Reach out.
this.fromLocation = App.args[0];
this.toLocation = App.args[1];
}
}
and your App
entry point looks like:
class App {
static String[] args;
public static void main(String args[]) {
App.args = args;
}
}
There are dire warnings here. Firstly, every app that uses your singleton will break if you do not start it at App.main
. Secondly, if you access your singleton anywhere in your App
class, it will probably break.