harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bootjvm@earthlink.net" <boot...@earthlink.net>
Subject Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Date Fri, 04 Nov 2005 16:50:33 GMT


> -----Original Message-----
> From: "Geir Magnusson Jr." <geirm@apache.org>
> 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

Mime
View raw message