harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Date Fri, 04 Nov 2005 23:20:16 GMT
bootjvm@earthlink.net wrote:

> 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
> directory structure './bootclasspath/java/lang/...' if so instructed.  The purpose of
> is to read in default class files from your current JDK for getting things started. 
> 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!


> ...snip...
> Dan Lydick


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message