>>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 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, Pete
