Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <1416.217.79.102.107.1117793887.squirrel@www.edworthy.org>
Date: Fri, 3 Jun 2005 11:18:07 +0100 (BST)
Subject: Re: [arch] VM/Classlibrary interface
From: "Peter Edworthy" <peter@edworthy.org>
To: harmony-dev@incubator.apache.org
Reply-To: peter@edworthy.org
User-Agent: SquirrelMail/1.4.4-3.cc
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

Hello,

>> And you can circumvent the language protection (package private...)
>> if you work hard enough too, I believe...
>>
>> Keeping out of "java.lang" seems wise if we can arrange it...
I agree, but ClassPath has its interface classes in Java.lang and while we
can and probably should implement these as an adapter level to our
internal system abstraction I can see why the JVM providing

# java.lang.Class
# java.lang.Runtime
# java.lang.Thread
# java.lang.reflect.Constructor
# java.lang.reflect.Method
# java.lang.reflect.Field

makes sense, as these are completely dependant on information only
available to the JVM. ClassPath could implement these objects and then
have them call across to, say, jvm.implementation.* objects but this adds
an extra level of indirection with no increase in flexibility of the
implementation.

The other java.lang.VM* objects I agree should really not be in
Java.lang.* but having references to these use an explicit ClassLoader
mitigates this into a cosmetic issue.

> It seems to me that control of 'java.lang' and 'java.lang.*' would
> be the simplest way to deal with issues of control of the implementation
> so that it is a Harmony implementation, not one from Sun, IBM, FSF,
> Sourceforge.* or anyone else.  From the Sun JDK 1.5.0 src.zip, there
> are 49 distinct 'sun.*' imports in the 'java.lang' package, none of
> which are found in this archive:

I wasn't aware that we were trying to restrict the possible ClassLibs that
could be used. In an ideal world we would want to make switching between
ClassPath and Jikes's implementations easy, encouraging the user to use
the most efficient implementation. (see next email for suggestions of mix
and match implementations).

> ...snip...

> By writing _only_ java.lang and java.lang.*,
> we can truly speak of a separate implementation.
> Adding only _parts_ of libraries like GNU ClassPath
> would mean that users would implement Harmony library
> policies, not Sun's, FSF's, or anybody elses.
>
> This implemetation of java.lang and java.lang.*
> is only 165 classes in 53K lines of code, not
> including native code.  Doable by this group
> without a doubt.

Even better than that the ClassPath project has already done this. As I
understand it, we are discussing methods of interfacing with the ClassPath
project in such a way that;
other implementations can be plugged in with minimal coding,
changes to the Java API do not require changes to the JVM, only the
ClassLibs.

Thanks,
Peter