Error initializing static fields that refer to one another

Question

I think I've found an error in some of my code, though it doesn't appear to rear its head in all situations. I'm hoping someone smarter than me can definitively say "Yes, this is an error", and better yet, to suggest an another alternative to my implementation.

I believe the source of the error is how the static fields of two classes are initialized; one (in FooClass) is initialized by referring to the other's field, and one (in MyUtility) is initialized by creating an object of type Foo. Sorry that sounds off; explanation was never my strong point.

I've spent the better part of a day trying to reduce the problem, and have something runnable that appears to demonstrate the problem.

public class Tester {

    static class FooClass {
        static final FooClass ITS_FOO = MyUtility.MY_FOO;
    }

    static class MyUtility {
        static final FooClass MY_FOO = new FooClass();

        static FooClass create() {
            return new FooClass();
        }
    }

    public static void main(String[] args) {
        System.out.println("utility's: " + MyUtility.create()); // Line "A"
        System.out.println("class's:   " + FooClass.ITS_FOO);   // Line "B"
    }
}

I realize this design looks odd, but won't try to justify it much (the real code is structured "oddly" too, but within separate classes with different visibility etc). I would definitely appreciate suggestions for better ways to do this.

The gist of the problem (at least with this program) is that the FooClass.ITS_FOO field is null when line B executes. If I switch the order of lines A and B, neither of the fields are null.

I've seen questions like In what order do static initializer blocks in Java run?, but neither that nor the Java Language Spec appear to describe how this kind of mutually referential initialization is done.

Unfortunately, this sample is so far removed from our real implementation that I'll probably spend the same amount of time translating any solution back, but that will be worth it to get some explanation.

score 4 · Accepted Answer · answered Mar 14 '12 at 18:19

4

Yes, if you force FooClass to initialize first, then that will trigger MyUtility initializing. The initializer for MY_FOO will proceed because FooClass is already initializing in this thread, so MY_FOO will be non-null.

On the other hand, if you observe ITS_FOO from the FooClass constructor (currently just defaulted), you'll see it's null there...

This behaviour is well documented in the spec - the section you've linked to gives all the details - but basically it's a really bad idea to have two types whose static initializers refer to each other. Don't try to fix it in subtle ways: get rid of the dependency. I realize this may be a pain, but really, it's not worth thinking about any other fix.

One way of performing that fix may be to extract a third type with a static initializer which doesn't depend on any other types, and which both of the other types can depend on.

Of course, doing less in your static initializers is also helpful :)

answered Mar 14 '12 at 18:19

Jon Skeet

1,421,763
867
9,128
9,194

Unfortunately (w.r.t. your third-type fix), the fundamental part of the design is that `FooClass.ITS_FOO` field being a special kind of `FooClass`. Simplifying my example got rid of that fact :(. But I'm still surprised the constructor can be executing before the class is initialized (though that sounds kind of magic to make it work in this case). In any case, I'll think on a way to get rid of one of the dependencies; that does sound like a bad idea now... – Rob I Mar 14 '12 at 18:31
@Rob: It's covered by this point from section 12.4.2: "If the Class object for C indicates that initialization is in progress for C by the current thread, then this must be a recursive request for initialization. Release LC and complete normally." – Jon Skeet Mar 14 '12 at 18:32
Ahh! I didn't quite follow that wording before, but now I see that this case and its "complete normally" is misleading... leading to the "really bad idea". Thanks! – Rob I Mar 14 '12 at 18:50
Followup question: is the "really bad idea" only tied to static initializer blocks, or any static initialization (such as fields)? – Rob I Mar 06 '13 at 15:45
1

@RobI: Any static initialization. Fundamentally one type's going to start being initialized first, triggering the other - which will refer to the first type's incomplete data. – Jon Skeet Mar 06 '13 at 15:46

Error initializing static fields that refer to one another

1 Answers1