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/lang /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
