RE: [cp-patches] RFC: Class Loader patch to record class withinitiating class loader

[Jeroen Frijters]

Mark Wielaard wrote:
> 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().

I agree that the call to registerInitiatingLoader() in
ClassLoader.defineClass() is a bit iffy. The reason I left it in there
is to not break any VMs when I check in this patch. I was a bit
surprised by the fact that two people complained that JamVM broke with
cvs head after my changes (I wasn't surprised that it broke, but I was
surprised that people actually ran into this without knowing how to
solve it). So I tried to be more careful with this change.

Do you have any suggestion on how to proceed with these type of changes
in general?

> 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.

It is already possible to keep the table completely in the VM (in fact,
this is what IKVM does), but you cannot get rid of the call in
Class.forName() because the VM is not involved in that process.

Regards,
Jeroen