Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <42A4572C.10608@cornell.edu>
References: <41200560565615260@earthlink.net>
	 <1118010384.2547.9.camel@localhost>
 <1118012440.17789.12.camel@qcplx01.physto.se> <42A4572C.10608@cornell.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A9983525-670A-41D9-99CE-D2F154AF94DF@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: [arch] How much of java.* and friends does Harmony need	towrite.
 Was: VM/Classlibrary interface
Date: Mon, 6 Jun 2005 11:22:42 -0400
To: harmony-dev@incubator.apache.org


On Jun 6, 2005, at 10:01 AM, Aaron Hamid wrote:

> Gah.  :(
>
> So if I am to understand this correctly: Classpath java.lang.*  
> implementation does not rely on specifics of any given VM*  
> interface implementation, but said VM* interface implementations  
> MAY rely on internals of existing Classpath java.lang.* classes?  
> (so there is a one-way dependency from the VM* implementation to  
> Classpath but not vice-versa, hence the "out of the box" claims?)   
> And through deduction, "standardizing" this VM* interface would  
> also entail "standardizing" reverse access to the class lib  
> java.lang.* implementations (either through some informal agreement  
> on package visibility members *yuck*, or through a more  
> sophisticated, but more cumbersome, API)?

Doesn't this imply that the GNU Classpath interface should add a  
second API that *it* should comply with for symmetry?  That way you  
don't get dependencies on GNU Classpath internals?

geir

>
> Aaron
>
> Jeroen Frijters wrote:
>
>> You're missing the fact that moving these classes into another  
>> packages
>> creates another problem that is much worse. Namely that you often  
>> need
>> to access private state in the public classes, you can do that by  
>> living
>> in the same package, that's why the VM* classes live in the same  
>> package
>> as their public counterpart.
>>
>
> Sven de Marothy wrote:
>
>> On Mon, 2005-06-06 at 00:26 +0200, Santiago Gala wrote:
>>
>>> A few classes need to be modified:
>>>
>> You're a bit confused here. Of course the Classpath VM interface
>> requires the VM to provide certain classes. How else would it work?
>> That does not mean to say that classpath itself needs modification
>>
>
>

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