This isn't necessarily true.  A single class Foo can be loaded in
multiple class loaders so long as the common parents do not also load
Foo.  This means that static members of Foo may exist more than once:
each time the Foo class is loaded within a classloader, another
occurrence of Foo's static members comes into being .  Foo's static
initializer is also run each time the class is loaded.

Consider the following class Foo:

package dyn;

public class Foo {
   static {
       System.out.println("Class " + Foo.class + " loaded on CL="
               + Foo.class.getClassLoader());
   }
}

This class is not available on the bootstrap classpath: it's in a
separate directory called Dynamic relative to the working directory.
The main class

import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;

public class DCL {
   public static void main(String[] args) throws
MalformedURLException,
           ClassNotFoundException, InstantiationException,
IllegalAccessException {
       URLClassLoader cl1 =
               new URLClassLoader(
                       new URL[] { new URL(
                               "file:Dynamic/") });
       cl1.loadClass("dyn.Foo").newInstance();

       URLClassLoader cl2 =
               new URLClassLoader(
                       new URL[] { new URL(
                               "file:Dynamic/") });
       cl2.loadClass("dyn.Foo").newInstance();
   }
}

generates the output

Class class dyn.Foo loaded on CL=java.net.URLClassLoader@2e7263
Class class dyn.Foo loaded on CL=java.net.URLClassLoader@5eb0a9

Since Cavett hasn't told us what this "separate tool" is, it's
entirely possible that it's engaging in some dynamic classloading and
actually is running the static initializer for ObjectX twice (and
initializing static final members twice).

-o

Well clearly I was mistaken.  That's pretty frustrating too because I
looked this up before I posted, and the documentation and examples
seemed to indicate that there would be a copy of a static variable.

Even the JLS doesn't really say, it just says that non-private fields
are inherited.  I'm not sure how one is supposed to determine when
documentation, including the JLS, should be taken at face value and when
one has to experiment carefully to determine what the docs actually meant.

I'm not sure what else to add, other than I'm really fuming over having
missed that.

    It seems far-fetched, but I won't rule it out because
I'm unfamiliar with RMI.  If there's a way two JVM's can
share the same (for some value of "same") object, I'd bet
that's where to hunt for it.

This code runs an inherent risk of multiple instantiation of the 'someInfo'
variable, in a multi-threaded context.

So what is 'someInfo' supposed to be when multiple children instantiate?  It's
a suspect pattern to have different children instantiate a parent-class static
member with different values.  Part of the problem is that it creates a
dependency between not only the parent to the child class, but between child
classes.  Now they have to be aware of the semantics of specific String (not
enum?!) values in a shared variable.

Another problem is that class loading in a different order can cause
non-deterministic behavior - on some runs the 'someInfo' will settle
eventually to one value, on other runs to a different value.

If multiple threads grab the class, even via the same class loader, each
thread could instantiate the variable to a different value and use that value
locally throughout its run.  The value change might not be visible to the
other or any subsequent thread.

It is likely that removing this static variable will be a better solution than
trying to get all that right.