tDixon tDixon - 5 months ago 8x
Java Question

Java enum attributes returning null based on order of access

I was exploring enums in java to see how they could be abused and I came across a behaviour I couldn't explain. Consider the following class:

public class PROGRAM {

public enum ENUM {;
public enum ANIMALS {;
public enum CATS {

CATS(DOGS dog) {this.RIVAL = dog;}
public DOGS RIVAL;
public enum DOGS {

DOGS(CATS cat) {this.RIVAL = cat;}
public CATS RIVAL;

public static void main(String[] args) {

The first statement in the main function will print 'WEED', as expected. The second one will print 'null'. However, if you switch them around, i.e.


the first statement will print 'FELIX' and the second statement will now print 'null'. Is there anyone that can explain this phenomenon?

For reference, I'm running the Java(TM) SE Runtime Environment (build 1.8.0_05-b13)


This has to do with enums and class initialization.

First, enum is just a fancy class with constant fields. That is, the enum constants you declare are in reality just static fields. So

enum SomeEnum {

compiles to something similar to

final class SomeEnum extends Enum<SomeEnum> {
    public static final SomeEnum CONSTANT = new SomeEnum();

Second, static fields are initialized in the left to right order they appear in the source code.

Next, execute either the class variable initializers and static initializers of the class, or the field initializers of the interface, in textual order, as though they were a single block.

In the following

final class SomeEnum extends Enum<SomeEnum> {
    public static final SomeEnum CONSTANT = new SomeEnum();
    public static final SomeEnum CONSTANT_2 = new SomeEnum();

CONSTANT would be initialized first, and CONSTANT_2 second.

Third, an enum type will be [initialized][3] when you access one of its constants (which is really just a static field).

Fourth, if a class is currently being initialized by the current thread, you proceed normally.

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.

How does this all come together?



is evaluated like

DOGS rvial = cat.RIVAL;

The first access to GARFIELD forces the initialization of the enum type CATS. That begins initializing the enum constants in CATS. Compiled, those appear like

private static final CATS FELIX = new CATS(DOGS.AKAME);
private static final CATS GARFIELD = new CATS(DOGS.WEED);
private static final CATS BUBSY = new CATS(DOGS.GIN);

These get initialized in order. So FELIX goes first. As part of its new instance creation expression, it accesses DOGS.AKAME, where the type DOGS is not yet initialized, so Java starts initializing it. The DOGS enum type, compiled, looks like

private static final DOGS GIN = new DOGS(CATS.FELIX);
private static final DOGS WEED = new DOGS(CATS.BUBSY);
private static final DOGS AKAME = new DOGS(CATS.GARFIELD);

So we start with GIN. In its new instance creation expression, it tries to access CATS.FELIX. CATS is current being initialized, so we just continue. CATS.FELIX hasn't been assigned a value yet. It's currently in construction lower on the stack. So its value is null. So GIN.RIVALS gets a reference to null. The same happens to all DOGS' RIVAL.

When all of the DOGS are initialized, execution returns to

private static final CATS FELIX = new CATS(DOGS.AKAME);

where DOGS.AKAME now refers to a fully initialize DOGS object. That gets assigned to its CATS#RIVAL field. Same for each of the CATS. In other words, all the CATS' RIVAL field are assigned a DOGS reference, but not the other way around.

Reordering the statements simply determines which enum type gets initialized first.