harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Edworthy" <pe...@edworthy.org>
Subject Re: [arch] VM/Classlibrary interface
Date Sun, 29 May 2005 22:35:28 GMT
>>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
>>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 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.

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'm open to suggestions of how best to mark the ClassLoader as the 'VM
implementation ClassLoader' as of cause an interface marking it would have
to be at the ClassPath( java(x).*) level. I don't like relying on it being
the bootstrap ClassLoader as this may be being used in a separate
ClassLoader space within another JVM.

I hope that all make sense,

View raw message