Fred Gray wrote: > > It's a straightforward bootstrapping problem, and it's apparently already been > solved once in the past. See the javadoc for Runtime.setSecurityManager(): > > This was moved to Runtime so that Runtime would no longer trigger > System's class initializer. Runtime does native library loading, and > the System class initializer requires native libraries to have been > loaded. > > The world starts out by initializing java.lang.Object. Its static initializer > does a System.loadLibrary(), which causes System to be initialized. The static > initializer for System again calls System.loadLibrary(), which in turn calls > Runtime.load(), causing Runtime to be initialized. The static initializer for > Runtime calls System.getProperty(), but the properties table hasn't been > constructed yet, so "properties.getProperty(key)" tries to follow a null > pointer. Therefore the world ends in a giant kaboom. :-)
I did some shuffling and analysis, and I think the latest version in Classpath has a safe bootstrap sequence. Can you please test it for me? I did not trace the initialization of ClassLoader; I'm hoping that it does not cause problems before the native libraries are loaded, but it appears to me that System.getProperty should now be working before the ClassLoader initialization begins. Quoting from the patch I made to Runtime.defaultProperties: ... * No matter what class you start initialization with, it defers to the * superclass, therefore Object.<clinit> will be the first Java code * executed. From there, the bootstrap sequence, up to the point that * native libraries are loaded (as of March 24, when I traced this * manually) is as follows: * * Object.<clinit> uses a String literal, possibly triggering initialization * String.<clinit> calls WeakHashMap.<init>, triggering initialization * AbstractMap, WeakHashMap, WeakHashMap$1 have no dependencies * String.<clinit> calls CaseInsensitiveComparator.<init>, triggering * initialization * CaseInsensitiveComparator has no dependencies * Object.<clinit> calls System.loadLibrary, triggering initialization * System.<clinit> calls System.loadLibrary * System.loadLibrary calls Runtime.getRuntime, triggering initialization * Runtime.<clinit> calls Properties.<init>, triggering initialization * Dictionary, Hashtable, and Properties have no dependencies * Runtime.<clinit> calls insertSystemProperties; the VM must make sure * that there are not any harmful dependencies * Runtime.<clinit> calls Runtime.<init> * Runtime.<init> calls StringTokenizer.<init>, triggering initialization * StringTokenizer has no dependencies * System.loadLibrary calls Runtime.loadLibrary * Runtime.loadLibrary should be able to load the library, although it * will probably set off another string of initializations from * ClassLoader first */ 2002-03-25 Eric Blake <[EMAIL PROTECTED]> * vm/reference/java/lang/Runtime.java (defaultProperties): New field, to work around bootstrap issue. (securityManager): Make package visible. (Runtime): Remove bootstrap dependencies from constructor. * vm/reference/java/lang/Thread.java: Use securityManager field directly. * vm/reference/java/lang/VMSystem.java (insertSystemProperties): Move to Runtime, for bootstrap issue. * java/lang/Object.java: Document bootstrap importance. * java/lang/String.java: Ditto. * java/lang/ThreadGroup.java: Use securityManager field directly. * java/lang/System.java (defaultProperties): Remove, to work around bootstrap issue. * java/util/Dictionary.java: Document bootstrap importance. * java/util/Hashtable.java: Ditto. * java/util/Propeties.java: Ditto. * java/util/StringTokenizer.java: Ditto. * java/util/WeakHashMap.java: Ditto. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath