I wrote: > This seems to be a fairly critical part of the classloader security > architecture that is simply not documented. This makes it rather difficult > to know how it is supposed to be implemented.
Okay I found something that documents this and it is not what I thought. The SecurityManager allows for checking (and hence denying) package access during classloading (directly or via reflection) but you only get that protection when you use a classloader that provides it. At present there is only one classloader that documents that it will do a package access check, and that is the classloader returned by URLClassLoader.newInstance. This information came from a 2001 JDC TechTips article: http://java.sun.com/developer/JDCTechTips/2001/tt0130.html Now I don't see anything that says that the system/application classloader, or even the bootstrap loader couldn't perform this check - but I'm not sure it would be such a good idea, or help that much. The question is: what were we trying to protect and under what conditions? As I understand it the intent was to have a public class with public methods that was meant to be inaccessible to anything not loaded by the bootstrap loader. That would imply making the system classloader implement this check. However, such a check would only occur when a security manager is installed anyway, so what exactly are we trying to protect here? Cheers, David _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
