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
