[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: VMClassLoader
From: |
Jeroen Frijters |
Subject: |
RE: VMClassLoader |
Date: |
Thu, 25 Sep 2003 09:32:58 +0200 |
Tom Tromey wrote:
> I think the reference VMClassLoader is subtly incorrect. Is anybody
> using this code as-is?
I am (in IKVM.NET).
> In particular, I think VMClassLoader.getSystemClassLoader must try to
> use the default system class loader to load the one specified in the
> java.system.class.loader property. Also, it should pass the default
> system loader as the argument to this loader's constructor.
>
> I base this on the Sun JDK docs for
> ClassLoader.getSystemClassLoader().
>
> Any opinions? I would check in a cleanup here, but I don't know how
> I would test it...
At the moment I rely on the current (incorrect) behavior. I wouldn't
mind fixing it, but I would like it if we could also remove
gnu.java.lang.SystemClassLoader and replace it with something that
actually works.
My current application (aka system) class loader is simply a
URLClassLoader and it has the extension class loader (another
URLClassLoader) as its parent. I don't see the need for
gnu.java.lang.SystemClassLoader, but I might be missing something.
My proposed implementation of VMClassLoader.getSystemClassLoader looks
something like this (pseudo code):
ClassLoader ext = new
URLClassLoader(toURLS(System.getProperty("java.ext.dirs")), null);
ClassLoader app = new
URLClassLoader(toURLS(System.getProperty("java.class.path")), ext);
String loader = System.getProperty("java.system.class.loader");
if(loader != null) {
Constructor c = Class.forName(loader, true, app).getConstructor(
new Class[] { ClassLoader.class } );
return (ClassLoader)c.newInstance(new Object[] { app });
} else {
return app;
}
Regards,
Jeroen
- VMClassLoader, Tom Tromey, 2003/09/24
- RE: VMClassLoader,
Jeroen Frijters <=