RE: A query on the classloader architecture

[Jeroen Frijters]

David Holmes wrote:
> These are questions for the different VM implementors out there.
> 
> 1. Is your bootstrap loader represented by null or an actual 
> Classloader instance?

By null.

> 2. Is your bootstrap loader and system/application 
> classloader the same object?

No.

> 3. Do you think your structure for the bootstrap and system 
> loader correctly reflect the expectations of the security
> architecture.

I don't know.

In case anyone cares, I'm struggling with a classloader architecture
issue myself. At the moment, all statically compiled code (and
pre-existing .NET classes) are loaded (or appear to be loaded) by the
bootstrap loader in IKVM. To me this makes perfect sense and it would
seem like the ideal solution, <rant>except for the fact that there is a
lot of code out there that expects that this.getClass().getClassLoader()
is not null. Most of the code is actually broken, because it simply
tries to load a resource, which could have also been accomplished by
doing this.getClass().getResourceAsStream(), which, of course, also
works if the classloader is null.</rant>

So I'm considering three options:
1) Add evil VM magic that allows
((ClassLoader)null).getResourceAsStream() to work.
2) Introduce an extension class loader that "loads" statically compiled
and pre-existing .NET classes.
3) Make the bootstrap classloader non-null.

All options have some obvious downsides:
1) Magic is rarely a good thing.
2) This introduces the possibility that the classloader architecture is
violated (classes loaded by the null classloader can refer to classes
loaded by the extension classloader). It's hard (or expensive) to guard
against this.
3) This would break code that assumes that the core classes have a null
classloader (I'm sure that exists as well).

Regards,
Jeroen