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)


Firstly, thank you very much for doing this analysis.

Mark Wielaard writes:
 > 
 > 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.

The issue of which class loader a compiled-in class should use is a
difficult one.  We don't have any specification to go by.  The fact
that Class.forName(String) and Class.forName(String, ClassLoader) are
different is obviously a bug.  Per has been assuming that
Class.forName("bla") will use the CLASSPATH, which doesn't seem
unreasonable.

My guess is that classes compiled into the application should be
assumed to be loaded through the system class loader, not the
bootstrap class loader.  My understanding is that the bootstrap class
loader only loads classes that are found in the boot classpath -- the
trusted runtime classes.  Application classes are loaded by the system
class loader.

But Tromey's comment in the HEAD gcj says:

  // This particular 'return' has been changed a couple of times over
  // libgcj's history.  This particular approach is a little weird,
  // because it means that all classes linked into the application
  // will see NULL for their class loader.  This may confuse some
  // applications that aren't expecting this; the solution is to use a
  // different linking model for these applications.  In the past we
  // returned the system class loader in this case, but that is
  // incorrect.  Also, back then we didn't have other linkage models
  // to fall back on.

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

Well, I think it can, but there might well be _other_ gcj applications
out there that make incorrect assumptions.

I'm not sure we should make such a change at this time.

Andrew.


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