20

I've started a rather large Enum of so called Descriptors that I've wanted to use as a reference list in my model. But now I've come across a compiler/VM limit the first time and so I'm looking for the best solution to handle this.

Here is my error : The code for the static initializer is exceeding the 65535 bytes limit

It is clear where this comes from - my Enum simply has far to much elements. But I need those elements - there is no way to reduce that set.

Initialy I've planed to use a single Enum because I want to make sure that all elements within the Enum are unique. It is used in a Hibernate persistence context where the reference to the Enum is stored as String value in the database. So this must be unique!

The content of my Enum can be devided into several groups of elements belonging together. But splitting the Enum would remove the unique safety I get during compile time. Or can this be achieved with multiple Enums in some way?

My only current idea is to define some Interface called Descriptor and code several Enums implementing it. This way I hope to be able to use the Hibernate Enum mapping as if it were a single Enum. But I'm not even sure if this will work. And I loose unique safety.

Any ideas how to handle that case?

Daniel Bleisteiner
  • 3,190
  • 1
  • 33
  • 47

5 Answers5

8

Simple. Don't use enum for this. You can't. It won't work.

The chances are that your source code does not explicitly refer to many of the enum values. Rather, you are using the enum as a convenient way to map between unique object instances and string names. So just replace the enum type with a type that explicitly manages the mapping, initializing it by reading from a file or database. If you do it right, you will get the computational properties and type-safety of an enum. The only thing you lose is the syntactic sugar ... and the statics.

This approach will have the added advantage that you can modify the 'descriptors' mapping without modifying the source code of your program.


By the way, the limitation you are running into is imposed by the JVM class file format. A method or constructor has an upper size limit of 2^16 bytes, and a classes static initialization code is represented as a special method with a funky name.

UPDATE

Unfortunately your self-answer solution will still run into a different 64K limit ... if pushed too far. Splitting the initialize() method gets around the method size limit, but there is also a 64K limit on the number of entries in a classes constant pool. Each String literal requires a constant pool entry.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I'm running into this because I want to do the exact opposite - pulling the rather static information of the descriptor into the code. It is currently a database table with roughly 1400 entries that I want to transfer into the code. The reason is more control over the data and easier handling in our large project. The topic is too complex to explain it short. Reading some kind of flat file with a singleton might be a way to go. Thanks for that idea. – Daniel Bleisteiner Mar 30 '10 at 19:10
  • @DanielBleisteiner - but I think that you will agree that your application does not strictly need an `enum` *per se* because you don't use the enum names in the source code. – Stephen C Feb 14 '14 at 04:09
  • Oh... resurrection of some very old thread. We work with many different classes in the way I've described it in my answer below. Our descriptors use acronyms which are unique and mapped via @PostLoad operations into the model. They work similar to Enums and are accessible via Descriptor.findByAcronym(...) and final static references to singletons in our code. – Daniel Bleisteiner Feb 14 '14 at 07:43
  • Methods are not limited to 64K. There are other problems, such as that the exception table can only cover 64K, and that the most common jump instructions jump with 16 bits integers. But an enum static initializer doesn't need exception handlers and a better compiler knows to generate wide jump instructions. So it's really a limitation in Javac (number of enum constants - not in general), that can be fixed by just fixing javac. – Erwin Bolwidt Jul 27 '16 at 15:08
5

This is not a simple solution, but you may try to... patch the Java compiler.

When you write an enum, the Java compiler generate a class which extends java.lang.Enum (possibly several classes, if there are constant-specific methods). The class has some (hidden) static fields, which, at the bytecode level, are initialized with the special <clinit>() method (which the JVM calls when the class is first used). As any other method, the code for the <clinit>() method is limited to 65535 bytes. Each constant contributes to about 20 to 22 bytes in the <clinit>() bytecode (more if there are constant-specific constructors), so you hit the limit at about 3000 enumeration constants.

Now the <clinit>() method has a funny name but it is nothing really special; it can invoke other methods. The Java compiler could split the mammoth <clinit>() into several hidden sub-methods which <clinit>() would then invoke one after the other. The Java compiler does not currently do that, but it theoretically could. The result would be processable by any JRE.

Alternatively, synthesize your enum class synthetically, generating bytecode from a dedicated program, possibly itself written in Java. In essence, this is like writing your own specialized compiler, for a specific target and using your own source syntax. The BCEL library may help.

Note that there are other limits which could jump on you. For each enumeration constant, the static code (the one in <clinit>()) uses two "constants", which are internal values aggregated in the "constant pool" part of the compiled class. The two values are the constant name (as a string) and the resulting static field reference. There is a hard limit on 65536 constant pool entries (indexes are on 16 bits), so no more than a bit more than 32000 enumeration constants. A patched Java compiler could walk around that limit by generating several hidden classes, each with its own constant pool. A harder limit is in the number of static fields: each enumeration constant becomes a static field in the "enum" class, and there can be no more than 65535 fields (static or not) in a class.

Thomas Pornin
  • 72,986
  • 14
  • 147
  • 189
  • I won't break compatibility of my java bytecode. That's no option. – Daniel Bleisteiner Mar 30 '10 at 19:11
  • 4
    I might have been unclear. The _whole point_ of my message is that it could be done while maintaining the bytecode fully compatible with what the JVM expects. – Thomas Pornin Mar 30 '10 at 20:14
  • 1
    Sounds like a fun project. You won't break *bytecode* compatibility, but you need a different *sourcecode*, because plain Java with javac fails. – Christian Semrau Aug 04 '11 at 21:17
  • We have encountered this problem. Latest Java 7 compilers actually split the static initializer automatically, but Eclipse Indigo's JDT compiler does not. This is a meaningful & insightful workaround to make an an equivalent Java class compileable in Indigo, which we are currently considering. – Thomas W Dec 16 '14 at 04:36
3

You can try the typesafe enum pattern described by Joshua Bloch in the first edition of his book "Effective Java".

The idea is to create a class with a private constructor. Inside this class you define static instances of any number you want to-just as in a Java enum.

I don't know if there is a limit for the number of static members in the Java language, though.

migu
  • 1,371
  • 1
  • 14
  • 23
  • That exactly seems to be so. The error states a limit of the static initializer code... not the enum itself. But I'll investigate this a little... thanks. – Daniel Bleisteiner Mar 30 '10 at 15:38
  • Then perhaps you have to create a fixed set of instances that are not static. However, that would make it impossible to use a constant like Suite.HEARTS directly. Your requirement seems to ask for quite an unusual solution. – migu Mar 30 '10 at 15:43
  • 1
    Thanks for your input here... I've come to a similar solution as described by that pattern. – Daniel Bleisteiner Mar 31 '10 at 10:27
  • The typesafe enum pattern link is 404. It should be https://stackoverflow.com/q/5092015/873282 now. - Even better, the answer should be self-contained. – koppor Apr 17 '20 at 16:07
0

You might try nesting static inner-classes within a top-level class

Everyone
  • 2,366
  • 2
  • 26
  • 39
0

My original idea was to map the Enum using the @Enumerated annotion. This would have looked like the following example:

@Enumerated(STRING)
private DescriptorEnum descriptor;

The database would have a column called DESCRIPTOR of type varchar and Hibernate (in my case) would map the string to the enumeration.

But I have that limit of 65k (see question) which is to small in my case. But I've found a solution. Have a look at the following example:

public final class Descriptor {
    public final String acronym;
    private static final Hashtable<String, Descriptor> all = new Hashtable<String, Descriptor>();
    static {
        initialize();
    }
    private static void initialize() {
        new Descriptor("example001");
        new Descriptor("example002");
        new Descriptor("example003");
    }
    private Descriptor(String acronym) {
        this.acronym = acronym;
        if (all.contains(this.acronym)) {
            throw new RuntimeException("duplicate acronym: " + this.acronym);
        }
        all.put(this.acronym, this);
    }
    public static Descriptor valueOf(String acronym) {
        return all.get(acronym);
    }
    public String value() {
        return this.acronym;
    }
}

This Descriptor class simulates the usage of a typical enum. But now I'm able to split the initialize() method into several ones that work around the 65k limit that also exists for methods. The Enum doesn't allow to split the initialization into several chunks - my class does.

Now I have to use a slightly different mapping though:

@Column(name = "DESCRIPTOR")
private String                  descriptorAcronym       = null;
private transient Descriptor    descriptor              = null;
public Descriptor getDescriptor() {
    return descriptor;
}
public void setDescriptor(Descriptor desc) {
    this.descriptor = desc;
    this.descriptorAcronym = desc != null ? desc.acronym : null;
}
public String getDescriptorAcronym() {
    return descriptorAcronym;
}
public void setDescriptorAcronym(String desc) {
    this.descriptorAcronym = desc;
    this.descriptor = desc != null ? Descriptor.valueOf(desc) : null;
}
@PostLoad
private void syncDescriptor() {
    this.descriptor = this.descriptorAcronym != null ? Descriptor.valueOf(this.descriptorAcronym) : null;
}

This way I can use the class like an Enum in most cases. It's a bit tricky... but it seems to work. Thanks for all the input that finally led me to that solution.

Daniel Bleisteiner
  • 3,190
  • 1
  • 33
  • 47