(Summary: "Settings" object either global or passed around like a red-
headed stepchild)

Congratulations -- you've just rediscovered the Singleton and the
Context Object patterns, of which in your case yes Singleton is to be
preferred. But you can avoid having a global variable as follows:

public class Settings {
   private static Settings instance = null;

   public final int field1;
   public final int field2;
   // etc.

   public static void initialize (int field1value, boolean
field2value, etc.) {
       synchronized (Settings.class) {
           if (instance != null) throw new IllegalStateException();
           instance = new Settings(field1value, field2value, etc.);
       }
   }

   private Settings (int field1value, boolean field2value, etc.) {
       field1 = field1value;
       field2 = field2value;
       // etc.
   }

   public Settings getInstance () {
       return instance;
   }
}

Now your Settings class is a proper Singleton, and the only public
fields are final, so there's no real global variables.

Your parameter-reading code would figure out field1value, field2value,
etc. and after all the parameters were read, invoke
Settings.initialize() with these local variables of main() as
arguments. Elsewhere in your code you would use
Settings.getInstance().field1 for instance, or cache a local reference
to the object returned by Settings.getInstance() and access its fields
in places where this is more efficient than constantly calling
getInstance.

The only global variable (in the way of static nonfinals) is
"instance", which is private to Settings. It clearly is only ever set
once, so it isn't genuinely a variable, just a constant that needs
initializing once. Hence "no real global variables". Thread-safety is
partial here, as initialize is synchronized on the Settings.class
Class object, and throws IllegalStateException if initialize is ever
called more than once (including concurrently), but getInstance
returns null before initialization, returns a fully-initialized
Settings object after, but may return a partially-initialized Settings
object until then because the JVM might actually allocate the Settings
object, assign the reference to "instance", and THEN run the
constructor instead of running the constructor before assigning the
reference. Synchronizing the getInstance method only helps in
multithreaded apps where threads that might access the instance are
running before initialization is definitely done; if your code is
single-threaded, or single-threaded until initialize() has returned,
you're safe. Synchronizing the getInstance method would make it
expensive and you may call it frequently, though calling it here and
there and caching the return value would relieve some of the burden.
Note that there's also the risk, in multithreaded code where you could
see a partially-constructed Settings, of seeing a null Settings too.
To be properly thread-safe for that scenario, it would probably be
necessary to make getInstance look like this:

public Settings getInstance () {
   synchronized (Settings.class) {
       if (instance != null) return instance;
       Settings.class.wait();
       return instance;
   }
}

and add "Settings.class.notifyAll();" just before the end of the
synchronized block in initialize(). This would cause threads calling
getInstance early to block until the singleton was initialized instead
of receiving a useless and probably-crash-provoking null for their
efforts.

Probably that is overkill for your needs though and it suffices to
launch no threads from the main thread and create no visible UI from
the main thread (which would bring the AWT/Swing event dispatch thread
into play) until the initialize() call has returned.

(There is also "double-checked locking" which is generally not thread-
safe however clever it seems. There's also this option:

public static void initialize (int field1value, boolean field2value,
etc.) {
   synchronized (Settings.class) {
       if (instance != null) throw new IllegalStateException();
   }
   Settings temp = new Settings(field1value, field2value, etc.);
   synchronized (Settings.class) {
       if (instance != null) throw new IllegalStateException();
       instance = temp;
   }
}

Assuming reference assignment is atomic, callers to the unsynchronized
getInstance implementation far above will always see either null or a
fully-constructed Settings. The price is sometimes creating an extra
Settings object and then throwing an exception instead of just
throwing an exception if multiple threads try to initialize the
singleton, which is unlikely for your implementation. A self-
initializing singleton is sometimes seen, where the singleton
constructor can find all the information it needs to initialize
itself, e.g. the AWT default toolkit singleton. This can use that
pattern if reference assignment is atomic:

public static Whatever getInstance () {
   if (instance != null) return instance;
   synchronized (something) {
       Whatever tempInstance;
       if (instance != null) return instance;
       synchronized (somethingElse) {
           tempInstance = new Whatever();
       }
       synchronized (anotherSomething) {
           if (instance != null) return instance;
           instance = tempInstance;
       }
       return instance;
   }
}

This only ever assigns instance once, and only ever returns instance,
and instance is null until after the object it will refer to is fully
constructed, so this is threadsafe as long as "instance =
tempInstance;" is atomic, i.e. instance == null tests true right up
until instance == tempInstance instead.) This requires "instance" be
declared "volatile" and a recent JVM be used; I don't know if it holds
even then. It's not dissimilar from double-checked locking, and is
really an elaboration of same. The inner synchronized blocks ensure
that "tempInstance = new Whatever()" and "instance = tempInstance"
cannot be reordered to run concurrently -- without the first block
moving some of "tempInstance = new Whatever()" (such as the
constructor call) into the second and after "instance = tempInstance"
could occur, and without the second "instance = tempInstance" could be
moved in between assigning the tempInstance reference and calling the
constructor. However, with both blocks it can't do either, since it
can't move stuff out of one synchronized block or cause the scopes of
the separate synchronizations to overlap (which could cause deadlock
when it has one lock and tries to acquire the second) either.

So far as I can tell if "volatile" works as advertised the above is
thread-safe, though klunky, and fast once instance != null, with only
the "volatile" penalty.)

On 26 Jul, 06:59, t...@milkyway.gsfc.nasa.gov wrote:

AFAICS - there are 2 reasons why ppl think global variables are a 'bad
thing'
1) Java is a pure OO language based on the idea that everything is an
object or static class. Using public static fields and public static
methods enables you to write code in the style (ie using the ideas of)
C or COBOL - but that is much more easily done in C or COBOL.
2) But STILL why shouldn't I? I think because of the advantages which
accrue from encapsulation ie (one of) the reasons why OOP was
developed. Having global variables around raises the possibility that
code will inadvertently assign 'invalid' (in some sense) values to
them.

So how about this. Your Settings class is either a singleton or a
static class. All data fields are private. You use public accessor
methods and mutator methods which validate proposed value changes.

Isn't this standard?