>>>>> "SG" == Sean Garagan <garaganat_private> writes: SG> I was actually quite surprised to see this when I wrote a SG> ClassLoader a while ago. I had wrongly assumed Sun would hard SG> code checks for the core Java classes. It looks like Sun SG> relies on proper security implementations to prevent the SG> ClassLoader from being replaced. Forcing java.lang.* to go through the system ClassLoader would be somewhat unfortunate in somce cases. There are circumstances (specifically in environments where you are handling potentially hostile foreign code) where you will want to either totally refuse access to some classes (java.lang.reflect leaps to mind), or redefine them (make methods final, or potentially remove some methods altogether). Yes - you're violating bits of the specification, but sometimes information leaks are things you really don't want. To reiterate, not protecting java.lang.* is *not*, IMHO, a bug. ClassLoaders are dangerous things, and you want to be very careful about who gets to play with them. And ClassLoader isn't the only class worth having a good, long look at. If you're trying to maintain the integrity of separate protection domains, all running foreign code but interacting in a single VM, then java.lang.Object is where you start worrying. m.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:06:43 PDT