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.()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.()V()
> > LOG: compiler_addi
