harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Date Mon, 06 Jun 2005 06:53:19 GMT
Jeroen Frijters wrote:

>You are correct, but why take the performance and complexity hit to
>solve a non-existing problem?
>  
>

The simpler solution is to just use class loaders as a modularization 
mechanism. It is possible (since I have done it in my OSGi framework) to 
create a class loader that handles libraries packaged as JAR files such 
that some packages are externally visible and some are not. Thus, the VM 
objects could be in another package and all have public access 
modifiers, but they would only be accessible to classes inside the JAR 
file, not outside of it.

Sure, it is not impossible to get access to the VM classes in this 
approach, but none of the proposed solutions offer this guarantee either.

-> richard


>Regards,
>Jeroen 
>
>  
>
>>-----Original Message-----
>>From: Aaron Hamid [mailto:arh14@cornell.edu] 
>>Sent: Sunday, June 05, 2005 20:44
>>To: harmony-dev@incubator.apache.org
>>Subject: Re: [arch] How much of java.* and friends does 
>>Harmony need to write. Was: VM/Classlibrary interface
>>
>>I actually had not considered this issue which would seem to warrant 
>>these classes living in the same package.  But can not an equivalent 
>>solution be constructed such that the implementations of these public 
>>classes can hand the VM* classes references to internal 
>>structures (and 
>>vice versa) though well defined interfaces, instead of relying on 
>>visibility modifiers to allow the VM* objects to access 
>>private state of 
>>java.lang classes, thereby allowing the VM* objects to live in a 
>>separate package?  Or am I misunderstanding your statement (or maybe 
>>that is just too cumbersome)?
>>
>>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.
>>>
>>>Regards,
>>>Jeroen
>>>      
>>>
>
>
>  
>

Mime
View raw message