For comparison, Wonka's explicit class initialisation looks something like this: ** 1) load class java/lang/Object. ** 2) load java/lang/Cloneable, java/lang/Serializable, java/lang/Throwable. ** 3) create clazz_Array. clazz_Array acts like clazzObject but has ** a modified method table and a modified interfaces table. ** It overrides the clone method of java/lang/Object and adds two ** new interfaces: Cloneable and Serializable. ** (We need to do this before any subclasses of Throwable are loaded, ** in order to ensure that they are marked CLAZZ_IS_THROWABLE). ** 4) load java/lang/Class, java/lang/ClassLoader, java/lang/Thread, ** java/lang/ThreadGroup, and java/lang/ref/Reference. ** 5) load all the classes mentioned in core-classes.in. ** 6) For each primitive class xxx, create: ** -An instance Class_xxx of class java/lang/Class, linked to ** a w_Clazz structure (clazz_xxx). ** The name associated with the Class instance is "xxx.class". ** -Entries in the array atype2clazz[], which is indexed by P_xxx.
Step 5) is needed because we need to create explicit relationships between C and Java constructs for quite a large number of classes, which Patrik doesn't need to do because he's using Oberon. I guess that's also why he doesn't need to explicitly load ClassLoader; we need to do that because of all the behind-the-scenes stuff needed to implement class loading according to the JVM spec. Best wishes Chris On Monday 20 October 2003 22:03, Patrik Reali wrote: > Hi! > > Initializing a JVM is quite a complicated thing. Many problems depend on > which class you first initialize, because this could cause unexpected > dependecies to pop up. > > Jaos doesn't suffer from the problem you descrive, because it doesn't use > the external libraries or JNI: Oberon is rather close to Java, and the > objects can be directly accessed from both languages without fear of > breaking the type system or confusing the garbage collector. > > I also had my share of problems with the system properties, because they > are hard-coded in the libraries and I didn't realize it at once. > Furthermore, the properties and java.io assume an unix-like filesystem, > which Oberon doesn't have: we don't have directories, only mounts. > > In Jaos, I explicitely initialize a few classes during bootstrap (this are > only the explicit calls, other classes may be automatically initialized as > side effect, and in fact about 80 are!). This code relies on classpath 0.5 > (I'm not through updating yet). > > 1. String > 2. Throwable > 3. StackTraceElement > 4. VMThrowable > 5. Thread > 6. ThreadGroup > 7. System > > This may look strange, but.... > > 1. String is implicitely used everywhere, because the string constants are > instances of this class; according to the spec, allocating an instance of a > class causes the class to be initialized. (I could avoid this, but then I > would have to protect every access to the string methods with a check to > launch initialization; Strings are already slow enough in Jaos). > > 2. Throwable / StackTraceElement / VMThrowable: I must allocate them when > the VM is launched: loading them on-demand (at the first exception) is > already too late, because the VM is already processing an exception (in > Oberon this is done with a software interrupt) and loading reads from the > disc (causing more interrupts), but the kernel doesn't allow to interrupt > handler to cause other interrupts. > > 3. Thread / ThreadGroup must be initialized, because every java program is > executed in a java thread; Jaos creates such a thread for the execution of > a java program. > > This remarks (in particular 2 and 3) are quite Jaos specific. > > This won't probably solve your problem, but may give you some insight about > the various problems encountered during the initialization phase. > > -Patrik > -------- > Patrik Reali > http://www.reali.ch/~patrik/ > http://www.oberon.ethz.ch/jaos > > > ----- Original Message ----- > From: "Joseph Wenninger" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, October 14, 2003 9:33 PM > Subject: classpath initialization > > > Hi > > > > I'm trying to use an unmodified classpath (0.06). I already have > > something working with a modified one. > > > > My problem is that the call stack during initialization of the System > > class I looks something like > > > > LOG: called: java/lang/System.<clinit>()V() > > LOG: called: > > java/lang/System.loadLibrary(Ljava/lang/String;)V(405c8488) > > LOG: called: java/lang/Runtime.getRuntime()Ljava/lang/Runtime;() > > LOG: finished: > > java/lang/Runtime.getRuntime()Ljava/lang/Runtime;->0x8420fd8 > > LOG: called: > > java/lang/Runtime.loadLibrary(Ljava/lang/String;)V(8420fd8, 405c8488) > > LOG: called: > > java/lang/VMSecurityManager.currentClassLoader()Ljava/lang/ClassLoader;() > > LOG: called: java/lang/ClassLoader.<clinit>()V() > > LOG: compiler_addinitclass: java/lang/VMClassLoader > > LOG: called: > > java/lang/VMClassLoader.getSystemClassLoader()Ljava/lang/ClassLoader;() > > LOG: called: > > java/lang/System.getProperty(Ljava/lang/String;Ljava/lang/String;)Ljava/lan >g /String;(405cb500, 405cb578) > > > ()V<i > > > > The last line causes an exception, since the static member properties > > isn't initialized yet. Did anybody else encounter such a problem ? I'm > > not sure if that it is a vm bug or a compiler problem or something that > > I miss > > > > Kind regards > > Joseph Wenninger > > > > > > > > _______________________________________________ > > Classpath mailing list > > [EMAIL PROTECTED] > > http://mail.gnu.org/mailman/listinfo/classpath > > _______________________________________________ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath -- Chris Gray /k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
