On Saturday 13 March 2004 10:13, Patrik Reali wrote: > --On Sonntag, 7. März 2004 16:02 +0100 Chris Gray <[EMAIL PROTECTED]> > > wrote: > > On Thursday 04 March 2004 09:01, Jeroen Frijters wrote: > >> David Holmes wrote: > >> > class Class is the first class that must be initialized [...] > >> > >> Given the wide variety of VMs that use Classpath, I'd be careful with > >> statements like these. For almost every such assumption there will be a > >> VM for which it isn't true. > > > > Amen. Wonka [doesn't use Classbath [yet], but] currently loads five > > other classes before java.lang.Class; java.lang.Object, > > java.lang.Cloneable, java.lang.Serializable, java.lang.Throwable, and > > the mysterious "array" class. > > You don't need java.lang.String from the beginning?
No. Our java.lang.String is just a wrapper for a w_string, and the VM uses w_string's internally: e.g. a Utf8 Constant is stored as a pointer to a w_string. So java.lang.String currently gets loaded a bit later, as part of the "core-classes.in" code. (This code also generates a global variable(!) called clazzString, so that native code can very easily generate instances of String, etc.). > Jaos is more exigent: > * java.lang.Object > * java.lang.String (also initialized) > * java.lang.RuntimeException > * java.lang.NullPointerException > * java.lang.ClassCastException > * java.lang.ArrayOutOfBoundariesException > * java.lang.OutOfMemoryException > * java.io.IOException > * java.lang.AbstractMethodException > * java.lang.Throwable (also initialized) > * java.lang.StackTraceElement (also initialized) > * java.lang.VMThrowable (also initialized) > * java.lang.Thread (also initialized) > * java.lang.ThreadGroup (also initialized) > * java.lang.System (also initialized) > > And obviously, many other follow implicitly when a class is initialized. We also had rather a long list in the past, but the code was so ugly and so fragile that I set about reducing it. I prefer to keep special-case code to a minimum. > You may ask why so many classes? Well, there are mainly two reasons. First, > I try to use as much java code as possible (I'm lazy), thus parts of the > JVM rely on the code in the libraries. A beautiful example are threads, > which rely on the Runnable interface: during the first implementation of > Jaos, the Oberon language didn't have interfaces, thus the threads where > started by invoking the Java code in java.lang.Thread; only later I did > integrate Jaos interface support in the Oberon Kernel and added them to the > language :-) . Of course, some functions must be duplicated for bootstrap > purposes, because they are needed before they become available. Yes, I like using Java code too. :) Currently we hack like hell to wrap up the first native thread in a java.lang.Thread, but the rest is fairly clean. This stuff will probably get a going-over soon when I do some work on JNI Activation, and I will be looking to use more Java not less. BTW there is another reason for "duplicate" code during bootstrap: you are often dealing with a more restricted case, and the execution time is reflected directly in the startup time for the VM. Initial class loading is a case in point. > Second, the exceptions are handled by Oberon's exception handler, which is > not able to load classes. All Exceptions that are generated by the compiler > or the CPU as interrupts must be already available in Throwable. And > obviously Throwable, StackTraceElement, and VMThrowable. We also used to pre-load all exception classes, once upon a time. But it was a helluva lot of stuff to be pre-loading, so now we only do it for a very few - basically the ones which can be thrown by the execution engine itself. So if the system class loader throws e.g. a FileNotFoundException we load that on the spot; if it also can't find FileNotFoundException.class then we just crash. :) What do you do if a class loaded by a user-defined class loader throws an exception which also has to be loaded by that user-defined class loader? Best wishes -- Chris Gray /k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 3 216 0369 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
