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] VM/Classlibrary interface
Date Sat, 28 May 2005 15:26:02 GMT
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...

-> richard



Mime
View raw message