> -----Original Message----- > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> > Sent: Nov 4, 2005 10:24 AM > To: harmony-dev@incubator.apache.org > Subject: VM/Class Library Interface (or "Storming the Gates! Take 3!") > > My favorite subject... > ... snip... > > 1) I didn't look at how jcheVM does it - although I assume that it > uses the canonical GNU Classpath approach - and I'm not sure that > bootVM code is there yet for that. I hope that Archie and Dan can > chime in with a summary of where things are. >
I've been evaluating Jean-Frederic's configuration proposal and finishing up on the core JVM code. I should have a _complete_ code base by the end of next week. Then I'll be doing some more with Robin Garner's proposal for design changes to the object model and GC issues. But before I get into that, I'll check in my SVN changes for this code base. At that time, we will need a Java bytecode test suite to verify that the opcode implementations are correct. After that, we will be ready to start with other things. Probably the _first_ thing that will need to be tested will be the built-in implementations of the java.lang classes Object, Class, String, and Thread. They are partly done, but will need to be tested and any remaining holes filled in. (See also comments below.) Notice that the current configuration script 'config.sh' will set up a default class path directory structure './bootclasspath/java/lang/...' if so instructed. The purpose of this is to read in default class files from your current JDK for getting things started. Notice that this will necessarily go away when we start working on fundamental classes. ...snip... > > 3) I'm really worried about the GNU Classpath interface that extends > java.lang. We do allow participants in this community to look at the > spec license, and we won't extend the defined namespaces in the spec. > Due to the fact that there is _so_ much java.lang code that defines native methods, and that those native methods deal with either the JVM core or with system(2) or library(3) calls, I set up a JNI abstraction in bootJVM that allows for implementation of those methods alongside or even within the JVM core. I have implemented a small slice of the following java.lang classes in this way: Object, Class, String, Thread. This does _not_ preclude the normal JNI approach, but that connection is a @todo items that needs writing. :-) The C source files for these is in 'jni/src/harmony/generic/0.0/src' with the shell of the Java source in its 'java/lang' subdirectory. For the rest of GNU Classpath, or any other library for that matter, I don't see why we couldn't use it as it stands. ...snip... > geir Dan Lydick
