Community
Participate
Working Groups
Build Identifier: 20100917-0705 We use a generated enum to statically reference certain reference data (which we want to be accessible in source code when created in a development environment). Adding or updating the entity causes the source file to be regenerated. The number of values now exceeds 2,500, which causes a compiler error in eclipse: The code for the static initializer is exceeding the 65535 bytes limit. However, when we build the code in Ant, there is no compile error. Checking the JVM limitations, I would expect a limit of 65,535 entries in an enum (see http://java.sun.com/docs/books/vmspec/html/ClassFile.doc.html#6253) and not a limit of 2,500. It appears that eclipse handles enum constants identically to static final constants. Imho this is wrong. Enum constants should be handled separately. There's a similar bug report for static final fields, suggesting that the class should be broken up and constants should be initialized in separate methods. This doesn't work in enums, because enums can not use inheritance. Reproducible: Always Steps to Reproduce: 1. Create an enum. Add 2,500+ entries. 2. Compile outside eclipse: compilation succeeds. 3. Compile in eclipse: compilation fails.
Created attachment 184033 [details] Example enum Attached an example enum.
P.S. we are working on a 64-bit machine. On 32-bit windows the limit would be 5,000.
(OpenJDK 6 x64) javac issues exactly the same error after a couple more elements; it's not an avoidable problem as far as I'm aware: EnumExample.java:15: code too large
(In reply to comment #0) > It appears that eclipse handles enum constants identically to static final > constants. Imho this is wrong. Enum constants should be handled separately. Please let me know why this would be a problem. The only way to "fix" this would be to split the initialization call from the clinit into multiple methods. I'll see what I can do.
(In reply to comment #3) > (OpenJDK 6 x64) javac issues exactly the same error after a couple more > elements; it's not an avoidable problem as far as I'm aware: > EnumExample.java:15: code too large Chris, you are absolutely correct. Sun JDK also generates 'code too large' when you add a few more items. The difference with eclipse is negligible. The issue should be closed. Thanks for the fast reply.
(In reply to comment #5) > Chris, you are absolutely correct. Sun JDK also generates 'code too large' when > you add a few more items. The difference with eclipse is negligible. > The issue should be closed. Thanks for the fast reply. I think it is worth investigating if we could simply insert the usage of synthetic methods when the number of constants is high. Might be simple to fix. In the JLS doesn't mention that limit of 2500+ enum constants. There is a limit in the code that can be generated for a method body and enum constants initialization must be generated as part of the clinit contents. But as far as I can say, there is nothing that prevents the usage of synthetic methods to initialize enum constants.
(In reply to comment #6) > In the JLS doesn't mention that limit of 2500+ enum constants. I guess the issue arises from some limitations in the JVM (that only a limited amount of memory can be allocated for certain features in a class file). For a programmer it would be very useful if the issue could be avoided by the compiler itself, rather than forcing him/her to refactor the code when you add one item too many.
(In reply to comment #7) > I guess the issue arises from some limitations in the JVM (that only a limited > amount of memory can be allocated for certain features in a class file). For a > programmer it would be very useful if the issue could be avoided by the > compiler itself, rather than forcing him/her to refactor the code when you add > one item too many. When you have more than 2000 enum constants, I think it is time to refactor :-). Anyway, I'll investigate if we can create synthetic methods to "factorize" the code automatically.
Created attachment 185509 [details] Proposed fix First draft. This compiles fine the given example. I'll add a regression test for this.
While this is a great idea; is there any way to turn back on the Sunracle compiler "bug", for those of us that have to ship Sunracle-compatible code? In this case it makes minimal difference, but if it's later expanded to do the same for method sizes and the like (there's no reason for it not to do so, except maybe that pesky spec, right?), it might be needed. Also, 2000 as a magic number twice in the patch. ¬_¬
I plan to release that patch as it is fixing the problem. I cannot rely on javac implementation to decide whether a fix should be released or not. Since the given example should compile according to the JLS, I treat this as a compiler bug. As is, it should be fixed since there is no workaround except splitting the enum constants into multiple enum declarations.
Released for 3.7M5. Regression test added in: org.eclipse.jdt.core.tests.compiler.regression.XLargeTest#test0016
Created attachment 186117 [details] Proposed fix + regression test Cleaned patch with regression test.
Verified for 3.7M5 using build I20110124-1800.
