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 Tue, 31 May 2005 19:44:02 GMT

On May 28, 2005, at 11:26 AM, Richard S. Hall wrote:

> Ulrich Kunitz wrote:
>
>
>> On Fri, 27 May 2005, Geir Magnusson Jr. wrote:
>>
>>
>>
>>> (Tomcat : I'd bet they fixed that (or will fix...))
>>>
>>> Well, can't the VM just prevent non-kernel code from using them?   
>>> Maybe
>>> overhead too high?
>>>
>>>
>>
>> You could play class loader games, however those could be
>> circumvented by just another customized class loader.
>>
>> Doug Lea discussed the general issue in a message to this mailing
>> list already. IMHO the problem is, that you can make a class only
>> public, package-private or visible for a single class (e.g.
>> private static). Some finer grained controls might be usefil like
>> exporting a class to a particular package.
>>
>> Doug referenced the paper
>> http://www.research.ibm.com/people/d/dgrove/papers/oopsla03.html
>> that discuesses a number of the issues involved and proposes a
>> solution based on a module concept. He referenced this page
>> http://www.cs.utah.edu/flux too.
>>
>>
>
> You can definitely get these types of features from "class loader  
> games", but somehow that sounds like a pejorative description. I  
> don't see why using class loaders for this purpose is not a good  
> idea, it is possible to create a pretty decent module system just  
> using class loaders and JAR files.
>
> I have just made available an alpha release of Oscar 2.0, my OSGi  
> framework implementation, with some extensions to the R3 version of  
> the specification:
>
>    http://oscar.objectweb.org/oscar-alpha.html
>
> There are basic capabilities, like a having a JAR declare what it  
> allows to be exported (and imported), but there are also more  
> advanced capabilities, like being able to include/exclude certain  
> classes from specific exported package. This latter capability  
> makes it possible to get around some of the limitations of Java's  
> access modifiers as they pertain to packages. In these situations,  
> the classes in the JAR file itself have complete access to their  
> contents, but external classes do not.
>
> This is all fairly easy and just requires that the classes be  
> packaged into JAR files with some metadata.
>
> As far as circumventing these capabilities using another customized  
> class loader, yes, they could create a URLClassLoader directly to a  
> module JAR file, which would ignore the metadata completely and  
> then they might be able to load classes directly from it. However,  
> this is going to a bit of effort to get at implementation details...

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

geir


>
> -> richard
>
>
>

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



Mime
View raw message