Hi, On Wed, 2005-07-27 at 13:18 +0200, Jeroen Frijters wrote: > While digging around the class loading issues, I discovered that we > didn't record a class with the "initiating loader" [1]. This is > necessary to maintain type safety in the face of buggy or malicious > class loaders (or even when the contents of the directories in the > classpath change).
With this patch I am not completely sure what the semantics of VMClassLoader.USE_VM_CACHE are. If it is set to true registerInitiatingLoader() is called everywhere, but not for ClassLoader.defineClass(). This seems to complicate the VM interface a bit since it looks like the runtime can do this optimization of registering the initiating class loader everywhere itself, not just with VMClassLoader.defineClass(). So can we make the changes mostly to the VMClass/VMClassLoader method contracts? And push the default registerInitiatingLoader() implementation into those classes where applicable. That makes it possible for the runtime to keep this table completely internal and then it doesn't have to rely on two callbacks from Class and ClassLoader on each defineClass/forName/loadClass call and we could get rid of loadedClasses field in ClassLoader completely. > I've also attached a Mauve test case that checks for everything I could > think of. Nice, thanks! Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
