From harmony-dev-return-2430-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Fri Nov 04 23:20:52 2005 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 48658 invoked from network); 4 Nov 2005 23:20:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Nov 2005 23:20:52 -0000 Received: (qmail 98710 invoked by uid 500); 4 Nov 2005 23:20:40 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 98650 invoked by uid 500); 4 Nov 2005 23:20:39 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 98639 invoked by uid 99); 4 Nov 2005 23:20:39 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 15:20:39 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=MANY_EXCLAMATIONS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 217.158.94.220 is neither permitted nor denied by domain of t.p.ellison@gmail.com) Received: from [217.158.94.220] (HELO cirrus.purplecloud.com) (217.158.94.220) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2005 15:20:34 -0800 Received: (qmail 75062 invoked from network); 4 Nov 2005 23:20:17 +0000 Received: from unknown (HELO ?192.168.0.2?) (85.133.120.161) by smtp.purplecloud.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Nov 2005 23:20:17 +0000 Message-ID: <436BECB0.5040603@gmail.com> Date: Fri, 04 Nov 2005 23:20:16 +0000 From: Tim Ellison User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en 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> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 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 (t.p.ellison@gmail.com) IBM Java technology centre, UK.