classpath
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]