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 Mon, 30 May 2005 07:23:28 GMT
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

View raw message