This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bootclassloader problem (gcc 4.0 regression)


Hi,

On Wed, 2005-04-13 at 00:40 -0700, Per Bothner wrote:
> The StackTrace in Class::forName (jstring className) find the correct
> klass, and does klass->getClassLoaderInternal().  That yields null,
> which is then passed to _Jv_FindClass.  The latter interprets null as
> the bootLoader, which as far as I can tell does *not* search the
> CLASS_PATH - not even the default "file:./".  I'm not sure though -
> this seems rather confusing.

OK this makes sense. You get this from gnu.expr.ModuleInfo which is
compiled into the application. Classes compiled into the application are
assumed to be loaded through the bootstrap class loader (null). The
bootstrap classloader should indeed not use the java.class.path
(CLASSPATH, etc). Only the system class loader should do this.
gcj 3.x had a bug that the bootstrap class loader also searched the
java.class.path for byte code class files. This is now never done
anymore except for classes in the java.endorsed.dirs.

What is confusing is the fact that Class.getClassLoader() has a special
hack for compiled in classes:

  [...] All gcj-compiled classes which
  // are linked into the application used to return `null' here, but
  // that confuses some poorly-written applications.  It is a useful
  // and apparently harmless compatibility hack to simply never return
  // `null' instead.
  return loader ? loader : ClassLoader::systemClassLoader;

What this means is that for compiled in classes of a binary
Class.getClassLoader() would return the system class loader, but
internally (in we use Class.getInternalClassLoader() which would return
null (indicating the bootstrap class loader). Which explains why now
loading with Class.forName("bla") fails but Class.forName("bla", true,
getClass().getClassLoader()) succeeds for you.

Ugly. I don't have a real solution for this yet.
Except to rewrite the kawa ModuleInfo.getInstance() to always explicitly
use ClassLoader.getSystemClassLoader().

One could say that classes compiled into an application should always
been seen as being loaded through the system class loader (that makes
sense to me at least). But I don't know if that can be done easily or
transparently.

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]