Re: classpath initialization

[Patrik Reali]

In Jaos, the ClassLoader is loaded but not really used (I'm still stuck with
classpath 0.5) because I have my own native implementation which overrides
the calls to Java's classloader in Class.fromName(). I'm currently upgrading
my implementation to work with 0.6 by moving all the native stuff into the
VM classes, but haven't got that far yet (it's a lot of work!)

-Patrik


> 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.