 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2005An enum mystery solved
I was baffled why the compiler would not let enum constructors access the enum's static variables. I consider it a bug, but an understandable bug. I think the reason is the enum invokes the constructors for the enum constants in static init code. Somebody was worried that the static initialisation would not be complete. Yet it is quite safe since the enum constants are the last bit of static init.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >I think the reason is the enum invokes the constructors for the enum >constants in static init code. Somebody was worried that the static >initialisation would not be complete. Yet it is quite safe since the >enum constants are the last bit of static init. I have placed an RFE with Sun to have the restriction repealed. In the meantime, oddly you can call static METHODS that access the static variables. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > In the > meantime, oddly you can call static METHODS that access the static > variables. This seems analogous to the "illegal forward reference" warning when one static final variable is refers to another static final (but not constant) variable but can get NullPointerException if the same forward reference is indirectly achieved using a static method. > I was baffled why the compiler would not let enum constructors access > the enum's static variables. If I understand the issue correctly, jls3 8.9 addresses this issue: It is compile-time error to reference a non-constant (§15.28) static field of an enum type from its constructors, instance initializer blocks, or instance variable initializer expressions. > I consider it a bug, but an understandable bug. > > I think the reason is the enum invokes the constructors for the enum > constants in static init code. Somebody was worried that the static > initialisation would not be complete. Yet it is quite safe since the > enum constants are the last bit of static init. A small test seems to indicate that enum constants are the /first/ bit of static init and that the static final variables are not initialized during this enum constant construction. Hemal Pandya wrote: > A small test seems to indicate that enum constants are the /first/ bit > of static init and that the static final variables are not initialized > during this enum constant construction. I think what Roedy missed was the distinction between a compile time constant and other static finals. A compile time constant will be inlined and therefore there is no problem. A static final initialised within static { }/<clinit> will cause a problem. enum Const { X; private static final int x = 1; // compile time constant private int i; Const() { i = x; // fine } } enum Final { X; private static final int x = false?null:1; // null is not constant private int i; Final() { i = x; // !! illegal reference to static field from initializer } } You can have a static final reference the enumerated. enum Ref { X; private static final Ref x = X; // fine } So constructors must run before user static initialisation. You should be able to access the static of other classes however. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >enum Final { > X; [quoted text clipped - 4 lines] > } >} Here is your code modified slightly to make it compile: enum Final { X; // enum constant private static final int x = Math.min(2,1); // final but not constant private int i; Final() { // i = x; // !! illegal reference to static field from initializer } } Here is how it decompiles: final class Final extends Enum { public static final Final[] values() { return (Final[])$VALUES.clone(); } public static Final valueOf(String s) { return (Final)Enum.valueOf(Final, s); } private Final(String s, int j) { super(s, j); } public static final Final X; private static final int x = Math.min(2, 1); private int i; private static final Final $VALUES[]; static { X = new Final("X", 0); $VALUES = (new Final[] { X }); } } You can see that had the i=x been allowed, it should have been fine. The constructors are run after the x = Math.min(2,1) are they not? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > private static final int x = Math.min(2,1); what term do you use to distinguish been a constant like this: private static final int X = Math.min(2,1); and like this: private static final int Y = 42; The second is known at compile time, can be used in case labels, is in-lineable. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > what term do you use to distinguish been a constant like this: > [quoted text clipped - 6 lines] > The second is known at compile time, can be used in case labels, is > in-lineable. The first is really just a static final, colloquially known as a constant. The latter is a "compile-time constant expression" according to the JLS 3rd Ed, 15.28, p525. I believe the second edition has some errata in that section about the use (or not) of nulls. There's some non-normative discussion about enum static initialisation in section 8.9 (Enums!), p252. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >constant. The latter is a "compile-time constant expression" according >to the JLS 3rd Ed, 15.28, p525. I believe the second edition has some >errata in that section about the use (or not) of nulls. I have written an essay on what I have discovered about constants. Other that the usual error checking, I invite you to submit some counter-intuitive examples on what is compile-time and what is a load-time constant. see http://mindprod.com/jgloss/constants.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > Here is your code modified slightly to make it compile: > [...] > Here is how it decompiles: > [...] > You can see that had the i=x been allowed, it should have been fine. > The constructors are run after the x = Math.min(2,1) are they not? I don't think you should depend upon your decompiler being accurate. javap -c is the way to go. You can see that the actual byte code is different from what your decompiler is claiming. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >I don't think you should depend upon your decompiler being accurate. >javap -c is the way to go. You can see that the actual byte code is >different from what your decompiler is claiming. You are such a clever character. You are right yet again. The compiler indeed does the static field inits AFTER the constructor calls. If it reversed the order, the way DJ decompiles it, Java would have no problem with static references in constructors. Here is the Javap decompilation of Final.java javap -c Final Compiled from "Final.java" final class Final extends java.lang.Enum{ public static final Final X; public static final Final[] values(); Code: 0: getstatic #1; //Field $VALUES:[LFinal; 3: invokevirtual #2; //Method "[LFinal;".clone:()Ljava/lang/Object; 6: checkcast #3; //class "[LFinal;" 9: areturn public static Final valueOf(java.lang.String); Code: 0: ldc_w #4; //class Final 3: aload_0 4: invokestatic #5; //Method java/lang/Enum.valueOf:(Ljava/lang/Class;Lj ava/lang/String;)Ljava/lang/Enum; 7: checkcast #4; //class Final 10: areturn static {}; Code: 0: new #4; //class Final 3: dup 4: ldc #7; //String X 6: iconst_0 7: invokespecial #8; //Method "<init>":(Ljava/lang/String;I)V 10: putstatic #9; //Field X:LFinal; 13: iconst_1 14: anewarray #4; //class Final 17: dup 18: iconst_0 19: getstatic #9; //Field X:LFinal; 22: aastore 23: putstatic #1; //Field $VALUES:[LFinal; 26: iconst_2 27: iconst_1 28: invokestatic #10; //Method java/lang/Math.min:(II)I 31: putstatic #11; //Field x:I 34: return } SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >>I don't think you should depend upon your decompiler being accurate. >>javap -c is the way to go. You can see that the actual byte code is [quoted text clipped - 4 lines] > calls. If it reversed the order, the way DJ decompiles it, Java would > have no problem with static references in constructors. But there would be problems with static references to the enum values, don't you think? So this may be a damned if do you, damned if you don't type situation. Ray SignatureXML is the programmer's duct tape. >But there would be problems with static references to the enum values, >don't you think? So this may be a damned if do you, damned if you don't >type situation. Ah ha! To solve that one you would need some sort of spread-sheet like natural ordering of the initialisations which would be very unJava-like. But then you'd think you could SET static values in constructors, just not reference them. Perhaps that is how it does work. I also want to recheck what their thinking is on compile time static constants. I suppose you get into similar situation if you have a pair of classes whose static inits cross reference each other. It is just that Java does not warn you of the problems. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >A small test seems to indicate that enum constants are the /first/ bit >of static init and that the static final variables are not initialized >during this enum constant construction. There is something deeply wrong when Java starts adding arbitrary restrictions like that making no sense in the high level language. I decompiled and discovered the construction of the enum constants came last. What is your code that the inits come after the construction? Why could not the compiler put it before and be done with this silly restriction, simultaneously making it safer to use static methods. here is an example: public enum Trees { PINE( true ), ASPEN ( false ); private static int coniferousCount; Trees( boolean coniferous ) { counter( coniferous ); } static void counter( boolean coniferous ) { if ( coniferous ) coniferousCount++; } } decompiles as: public final class Trees extends Enum { public static final Trees[] values() { return (Trees[])$VALUES.clone(); } public static Trees valueOf(String s) { return (Trees)Enum.valueOf(Trees, s); } private Trees(String s, int i, boolean flag) { super(s, i); counter(flag); } static void counter(boolean flag) { if(flag) coniferousCount++; } public static final Trees PINE; public static final Trees ASPEN; private static int coniferousCount; private static final Trees $VALUES[]; static { PINE = new Trees("PINE", 0, true); ASPEN = new Trees("ASPEN", 1, false); $VALUES = (new Trees[] { PINE, ASPEN }); } } SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >>A small test seems to indicate that enum constants are the /first/ bit >>of static init and that the static final variables are not initialized >>during this enum constant construction. > > There is something deeply wrong when Java starts adding arbitrary > restrictions like that making no sense in the high level language. Initialisation has got to be done in some order. Doing it in the order presented in the source code seems like the method of least surprises to me. > I decompiled and discovered the construction of the enum constants > came last. What is your code that the inits come after the [quoted text clipped - 22 lines] > > } This is an irrelevant example. It does not do any user static initialisation. Here's my example: enum Order { X; private static final long time = System.currentTimeMillis(); } $ javap -c Order ... static {}; Code: 0: new #4; //class Order 3: dup 4: ldc #7; //String X 6: iconst_0 7: invokespecial #8; //Method "<init>":(Ljava/lang/String;I)V 10: putstatic #9; //Field X:LOrder; 13: iconst_1 14: anewarray #4; //class Order 17: dup 18: iconst_0 19: getstatic #9; //Field X:LOrder; 22: aastore 23: putstatic #1; //Field $VALUES:[LOrder; 26: invokestatic #10; //Method java/lang/System.currentTimeMillis:()J 29: putstatic #11; //Field time:J 32: return Bytes [0, 13) creates the constant. Bytes [13, 26) do the rest of the enum initialisation. Bytes [26, 32) are my initialisation. Clearly the enum constants are created first. Which is useful if I wanted any static finals involving the enumeration that they are in. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.