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
[EMAIL PROTECTED]
