Community
Participate
Working Groups
According to the J2SE Specification : "It is a compile-time error for the class body of an enum constant to declare an abstract method.", but no error is reported in this case. Example: public enum Operation { PLUS { double eval(double x, double y) { return x + y; } }, MINUS { abstract double eval(double x, double y); }; abstract double eval(double x, double y); } When trying to use the class, the following exception appears in the console : Exception in thread "main" java.lang.ClassFormatError: Illegal class modifiers in class enumtest/Operation: 0x4412 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at enumtest.Main.main(Main.java:22)
Not only we don't detect this case, but we also don't detect abstract method not implemented. public enum X { PLUS { double eval(double x, double y) { return x + y; } }, MINUS { abstract void eval2(Object x, Object y); }; abstract double eval(double x, double y); public static void main(String[] args) {} } In this case, we don't detect that eval2 is abstract and we don't detect that eval is not implemented for MINUS. X ends up being abstract and this is also illegal. See JLS3 8.1.1.1
Created attachment 49701 [details] Proposed patch 3.3 patch
Created attachment 49705 [details] Better patch Improved patch, which also clarifies the AccFinal positionning. In the past, it was always set, and cleared during enum constant checkAndSetModifiers, which could allow for some discrepancy in the meantime.
Added EnumTest#test138-141. Released for 3.3M2 (HEAD) Will queue the change as well for 3.2.2 (too late for 3.2.1)
Verified for 3.3 M2 using build I20060918-0010.
Released for 3.2.2
*** Bug 166866 has been marked as a duplicate of this bug. ***
Reopen for verification
(In reply to comment #6) > Released for 3.2.2 >
verified for 3.2.2 using build M20070112-1200