Re: [cp-patches] RFC: Class Loader patch to record class with initiating class loader

[Mark Wielaard]

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