Peter Edworthy wrote:
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 agree.
Sadly I've left my copy of the Java 2 security model book at work, but
basically my understanding is ClassLoaders restricting access is the
correct solution. It provides the interface independence we are looking
for, i.e. changes to the VM interface and changes to the Java(x).*
interface are entirely independent. Yes it can be circumvented, but only
with access to the security settings and then anything could be done.
This does require support from 'ClassPath' type projects though, but any
solution requires an agreement of the interface between the JVM and the
java(x).* class libraries.
To me, this is the point. I would like to see all of the libraries built
on to of the JVM to be packaged in a more module-like fashion, so that
their exports and imports are explicit. There would be many benefits if
this were done, rather than relying on the current approach of assuming
that everything is accessible.
The implementation would be whenever a 'VM implementation' class is used
in 'ClassPath' or similar projects the 'VM implementation ClassLoader'
would have to be used. When a Java(x).* class was used the default loader
would be used, this explicitly seperates the namespace for JVM classes and
java(x).* classes. The obvious way to get this loader would be through
Object.getClassLoader() and ensuring the 'VM implementation ClassLoader'
was on the tree below the java(x).* ClassLoader.
I would like to see the situation where the tree delegation model is
replaced by an import/export graph model. From my perspective, the only
guarantee that a class loader should have to give about class access are
to the "core" classes (i.e., I would guess those in java.*).
Currently, Sun's class libraries make pretty broad assumptions about
which classes are accessible are available from ANY given class loader
and this causes problems if you are building a module-like system for
class loading where delegation is based on imports/exports. For example,
Sun's libraries assume that all Sun's implementation classes are
available from any class loader in certain cases for reflection. Swing
also makes the assumption that all Swing plaf classes are available from
all class loaders.
So, from my point of view, it is definitely going in the right direction
to make libraries understand which class loader they should use to get
to their own "module's" classes, as opposed to just assuming they can
get them from any application class loader.
-> richard
