[EMAIL PROTECTED] wrote: <<snip>> > 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.)
I agree with this approach Dan. We defined a set of these 'kernel' classes -- those that are intimately associated with the VM -- such that they form part of the VM-implementation and are part of the interface to the rest of the class library. I described the kernel classes a while ago (probably in one of Geir's last 'storming' ventures ;-) ). A combination of the kernel classes and the native VM interface I described earlier form the entire VM <-> class library interface. I hope to be able to share our code with everyone real soon. > 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. :-) Yes -- having that flexibility for the fundamental classes should remain part of the VM-implementor's architecture choice. > 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. That will be the acid test! Regards, Tim > ...snip... > > >>geir > > > > > > Dan Lydick > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
