Chris Gray wrote: > Oops my bad - I confused initialisation with loading. Then I > see that Wonka actually initialises both ThreadGroup and > Thread before Class, but OTOH I also know that the > initialisation of our ThreadGroup and Thread are subject > to special restrictions (because at that moment there is no > current Thread, and no Class instance can be created). > So David's statement is probably pretty close to being true > in a practical sense, as well as a JLS sense.
I don't necessarily agree or disagree, but I think it is important to keep an open mind about these things. On IKVM, I don't have any of the usual bootstrapping issues, so static initialization basically just happens whenever it is needed. For example, here is what my initialization looks like for "Hello, World!": C:\>ikvm -Xmethodtrace:clinit -Xtrace:*=off hello [11:56:26.75996 main] java.lang.System.<clinit>()V [11:56:26.76998 main] java.lang.Runtime.<clinit>()V [11:56:26.76998 main] java.lang.VMRuntime.<clinit>()V [11:56:26.77999 main] java.lang.StringHelper.<clinit>()V [11:56:26.80002 main] java.io.FileDescriptor.<clinit>()V [11:56:26.80002 main] java.io.PrintWriter.<clinit>()V [11:56:26.81004 main] gnu.java.io.EncodingManager.<clinit>()V [11:56:26.81004 main] java.lang.Class.<clinit>()V [11:56:26.88014 main] gnu.java.io.decode.Decoder.<clinit>()V [11:56:26.88014 main] gnu.java.io.decode.Decoder8859_1.<clinit>()V [11:56:26.90016 main] gnu.java.io.encode.Encoder.<clinit>()V [11:56:26.90016 main] gnu.java.io.encode.Encoder8859_1.<clinit>()V [11:56:26.90016 main] java.lang.ClassLoader.<clinit>()V [11:56:26.95024 main] java.io.File.<clinit>()V [11:56:26.95024 main] gnu.java.io.PlatformHelper.<clinit>()V [11:56:26.95024 main] java.lang.Character.<clinit>()V [11:56:26.95024 main] java.net.URL.<clinit>()V [11:56:26.96025 main] java.util.Locale.<clinit>()V [11:56:27.00031 main] java.net.URLClassLoader.<clinit>()V [11:56:27.00031 main] java.security.Policy.<clinit>()V [11:56:27.00031 main] gnu.java.security.provider.DefaultPolicy.<clinit>()V [11:56:27.01032 main] java.lang.ExceptionHelper.<clinit>()V [11:56:27.01032 main] java.util.WeakHashMap.<clinit>()V [11:56:27.02034 main] java.io.FilePermission.<clinit>()V [11:56:27.05038 main] java.lang.Number.<clinit>()V [11:56:27.05038 main] java.lang.Integer.<clinit>()V [11:56:27.19058 main] java.lang.Void.<clinit>()V Hello, World! [11:56:27.20060 ] java.lang.Thread.<clinit>()V [11:56:27.20060 ] java.lang.VMThread.<clinit>()V [11:56:27.21061 ] java.lang.ThreadGroup.<clinit>()V [11:56:27.21061 ] java.lang.ThreadLocal.<clinit>()V [11:56:27.21061 ] java.lang.InheritableThreadLocal.<clinit>()V [11:56:27.21061 ] java.util.Collections.<clinit>()V (As an aside, I just noticed the incredibly lame static initializer we have in Thread (to initialize a field to zero) and the fact that I have a static initializer in VMRuntime that isn't really needed.) Now having said all that, I'm certainly not opposed to making the unknownProtectionDomain initialization in Class lazy. In fact, it looks like a good optimization. Regards, Jeroen _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
