Patrick Doyle wrote:
> However, I don't think that's the central issue. There really is a
> fundamental initialization problem here:
> ...
> As classpath stands, I can't see any way to do this correctly. Am I
> missing it? What is the sequence of events which causes these things to
> be initialized properly?
>
> Then, assuming there is such a correct sequence, doesn't this code still
> seem somewhat obscure? Should it be rewritten so as not to rely so
> heavily on Java's precise initialization semantics, just for clarity?
I think you are expecting too much from the class libraries (Classpath).
It is OK for Classpath to have "recursive" dependecies, as long as
their expected behavior is consistent with the Java/JVM semantics except
while bootstrapping the VM.
It is the task of the VM to bootstrap itslef to some stable state where
it can start fulfilling the complete Java/JVM semantics, and it is not
the class libraries task to anticipate the needs of the various VMs for
minor/easily resolved issues like bootstrapping the String class. We
certainly do not want to add any overhead to String.intern(), or make
the String/Hastable code overly complex, just for the sake of
simplifying the initial VM bootstrapping.
I say this because you might have to face many other bootstrapping
problems in your VM. For example, imagine that you wanted to support
class loading out of .jar files, but you wanted to do it using
java.util.zip classes (why rewrite the whole thing in C/C++, when you
can have nice and robust code for it written in Java?). You really
don't want to bother the java.util.zip.* developers with your VM
initialization/class loading problems to make this possible, instead,
you want to handle these problems internally in you VM, keeping a nice
separation of concerns between the libraries and the VM (as much as is
possible).
As I said in another message, handling bootstrapping issues is not
difficult. Yes it requires some care, but it is easily achieved with a
special bootstrapping mode in your VM. While in bootstrapping mode, you
can decide not to fullfill all of the Java/JVM semantics, for various
reasons. One of such reasons is the impossibility to fullfill the
semantics, e.g.: during initialization, a "ClassFormatError" is detected
while parsing the "ClassFormatError.class" file...
I hope this will help you with your VM design.
Etienne
--
+--------------------------------------------------------------------+
| �tienne M. Gagnon mailto:[EMAIL PROTECTED] |
| Professeur adjoint T�l�phone: (514) 987-3000 poste 8215 |
| Bureau: PK-4930 T�l�copieur: (514) 987-8477 |
| D�partement d'informatique, UQ�M http://www.info.uqam.ca/ |
| Auteur de SableVM http://www.sablevm.org/ |
| et de SableCC http://www.sablecc.org/ |
+--------------------------------------------------------------------+
| Etienne M. Gagnon mailto:[EMAIL PROTECTED] |
| Assistant Professor Phone: (514) 987-3000 ext. 8215 |
| Office: PK-4930 Fax: (514) 987-8477 |
| Department of Computer Science, UQAM http://www.info.uqam.ca/ |
| Author of SableVM http://www.sablevm.org/ |
| and SableCC http://www.sablecc.org/ |
+--------------------------------------------------------------------+
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
