harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [arch] VM/Classlibrary interface
Date Sun, 05 Jun 2005 02:23:08 GMT

On Jun 3, 2005, at 7:18 AM, Peter Edworthy wrote:

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

Oops. I see that I wasn't clear.  I didn't meant that the VM  
shouldn't implement things from java.lang - it makes perfect sense  
that we do so.  What I was trying to say [sloppily] was that we  
shouldn't extend java.lang w/ new classes or interfaces.  Sorry.

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

Yes

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

yes, and it would be cool if we could concoct an adapter for Sun's  
implementation as well for fun :)

Making the interfaces between VM and class library standard should be  
something we do now, starting with GNU Classpath's interface, and  
figuring out what else we might need based on experiences of others  
<cough>IBM/Intel/BEA</cough> doing the same thing.

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

Well, two comments :

1) we clearly want to interface w/ GNU Classpath, but we want to  
generalize thought whatever we can learn from others.

2) I don't know for sure, but guess that as time goes on and the Java  
API evolves, it might require additions to the JVM/Classlib API

geir

>
> Thanks,
> Peter
>
>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message