> I'm pretty sure the check *cannot* be circumvented by a user-defined > class loader. It may not do the check itself, but that only means it can > load a class in another package (that happens to have the same name). > For it to load bootstrap classes, it will need to delegate to the system > class loader and that's the one doing the checking.
That assumes that the test is unconditionally performed in loadClass - in which case you can't circumvent the check. I'm not clear on exactly what the merits of this mechanism are in general, but I guess that the primary motivation is to deny access to untrusted code, rather than just user-code. I'm not sure what dire consequences would arise from accessing these system properties, but it is probably much less dire than someone accessing sun.misc.unsafe :) Question: is the classpath security implementation at the stage where it supports policy files etc? Do individual VM's define where the policy file should be found? David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
