Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <436BC012.7040908@telefonica.net>
Date: Fri, 04 Nov 2005 21:09:54 +0100
From: Jean-frederic Clere <jfclere@telefonica.net>
Reply-To: jfclere@sinix.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041023
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: VM/Class Library Interface (or "Storming the Gates!  Take 3!")
References: 
 <20441193.1131123033297.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
In-Reply-To: 
 <20441193.1131123033297.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

bootjvm@earthlink.net wrote:

>  
>
>>-----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.
>  
>
What about commit often, release often.

>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.
>  
>
That should one option more for the autoconf/configure stuff.

Cheers

Jean-Frederic

>...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
>
>  
>