How to reference a static variable before the static initializer runs

Question

I'm anything but new to Java. Nevertheless, one discovers something new ever' once n a while. (At least I think so; correct me if I'm wrong in this.)
I've long thought it impossible to reference a static variable on a class without the class' static initializer running first. But I seem to have discovered a way:
public class Foo  {
  public static final SumClass fooVar;  // by default initialized to null
  static  {
     fooVar = new SumClass();
public class Bar  {
  public static final SumClass barVar;
  static  {
     barVar = Foo.fooVar;  // <<<--- set to null !
}Warning: Speculation ahead.
Normally the initial reference to Foo would cause Foo's class object to instantiate, initializing Foo's static variables, then running static{}. But apparently a static initializer cannot be triggered from within another static initializer. Can anyone confirm?
How to fix/avoid: Obviously, one could avoid use of the static initializer. The illustration doesn't call for it.
public class Foo  {
  public static final SumClass fooVar = new SumClass();  // either this ..
public class Bar  {
  public static final SumClass barVar = Foo.fooVar;  // .. or this would prevent the problem
}But there are times when you need to use it.
So what's an elegant way to avoid the problem?

Answer 1

DMF. wrote:
jschell wrote:
But there are times when you need to use it. I seriously doubt that.
I would suppose that if one did "need" to use it it would only be once in ones entire professional career.Try an initializer that requires several statements. Josh Bloch illustrates one in an early chapter of Effective Java, IIRC.
Another classic usage is for Singletons. You can make one look like a Monostate and avoid the annoying instance() invocation. Sure, it's not the only way, but it's a good one.
What? You only encounter those once in a career? We must have very different careers. ;)
So what's an elegant way to avoid the problem? Redesign. Not because it is elegant but rather to correct the error in the design.<pff> You have no idea what my design looks like; I just drew you a couple of stick figures.If it's dependent on such things as when a static initializer runs, it's poor. That's avoidable. Mentioning a case where such a dependency is used, that's irrelevant. It can be avoided. I know this is the point where you come up with a series of unfortunate coincidences that somehow dictate that you must use such a thing, but the very fact that you're pondering the problem with the design is a design problem. By definition.
Besides, since what I was supposing to be a problem wasn't a problem, your "solution" isn't a solution. Is it?Well, you did ask the exact question "So what's an elegant way to avoid the problem?". If you didn't want it answered, you should have said so. I'm wondering if there could be any answer to that question that wouldn't cause you to respond in such a snippy manner. Your design is supposedly problematic, as evidenced by your question. I fail to see why the answer "re-design" is unacceptable. Maybe "change the way the Java runtime initializes classes" would have been better?
This thread is bizarre. Why ask a question to which the only sane answer, you have already ruled out?