Question

The following code fails with a NullPointerException in main (map==null).
The issue occurs only if I define 2001 or more Enum constants, 2000 work fine.

Why isn’t the static code block not executed?

Do we hit any silent limit of the compiler (no warnings, no errors) or JVM?

The compiled class file exceeds 172KB,

import java.util.HashMap;

public enum EnumTest {
    E(1),E(2),...,E(2001);

    private static HashMap<Integer, EnumTest>   map = new HashMap<Integer, EnumTest>();

    static {

        for ( EnumTest f : EnumTest.values() ) {
            map.put( (int) f.id, f );
        }
    }
    short id;

    private EnumTest(int id) {
        this.id = (short) id;
    };

    public short getId() {
        return id;
    }

    public static final EnumTest fromInt(int id) {
        EnumTest e = map.get( id );
        if ( e != null ) {
            return e;
        }
        throw new IllegalArgumentException( "" + id );
    }

    public static void main(String[] args) {
        System.out.println( "size:" + map.size() );
    }
}

Runtime Environment:

java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)

also happens with:

java version "1.6.0_32" Java(TM) SE Runtime Environment (build
1.6.0_32-b05) Java HotSpot(TM) Client VM (build 20.7-b02, mixed mode, sharing)

Answer 1

These kinds of problems come from the fact that some (often compiler-generated) initializer code exceeds 65536 bytes of byte code. A single method can not contain more than that many bytes of bytecode to be executed (due to restrictions in the class file format).

A common source of problems like this are large arrays like this:

byte someBytes = { 1, 2, 3, ..., someBigValue };

The problem here is that such fields are actually initialized with someBigValue assignment statements in a generated initializer (constructor or static initializer).

Enum values are actually initialized in a similar fashion.

Given the following enum class:

public enum Foo {
  CONSTANT(1);

  private Foo(int i) {
  }
}

We look at the output of javap -v and see the following code block:

  static {};
    flags: ACC_STATIC
    Code:
      stack=5, locals=0, args_size=0
         0: new           #4                  // class Foo
         3: dup
         4: ldc           #7                  // String CONSTANT
         6: iconst_0
         7: iconst_1
         8: invokespecial #8                  // Method "<init>":(Ljava/lang/String;II)V
        11: putstatic     #9                  // Field CONSTANT:LFoo;
        14: iconst_1
        15: anewarray     #4                  // class Foo
        18: dup
        19: iconst_0
        20: getstatic     #9                  // Field CONSTANT:LFoo;
        23: aastore
        24: putstatic     #1                  // Field $VALUES:[LFoo;
        27: return

As you can see there are quite a lot of bytecode operations that handle instantiating CONSTANT with the correct values. If you have many such enum values, then the size of that static initializer block can easily exceed 64k bytes of code and thus make the class uncompilable.

A possible workaround is to reduce the size of the initializing code by reducing the number of arguments (for example by calculating the number passed in based on the index of the enum value instead of using an argument). That might just give you enough wiggle room to extend this a bit further.

Alternatively you could try splitting your enum into several enums connected by implementing a common interface. The enums could be grouped by area/intention/category/…:

public interface MessageType {
  int getId();
}

public enum ConnectionMessage implements MessageType {
  INIT_CONNECTION(1),
  LOGIN(2),
  LOGOUT(3),
  CLOSE_CONNECTION(4);

  // getId code, constructor, ...
}

public enum FrobnicationMessage implements MessageType {
  FROBNICATE_FOO(5),
  FROBNICATE_BAR(6),
  DEFROB_FOO(7),
  DEFROB_BAR(8),
  ...

  // getId code, constructor, ...
}

I’m assuming that the enum values are actually referenced somewhere in your code and not just pure value holders, if they only hold values and individual values are not treated differently in your code, then replacing them with a single class instantiated once per data item stored in a central resource is probably the best approach.