Re: bootclassloader problem (gcc 4.0 regression)

[Mark Wielaard <mark at klomp dot org>]

Hi Hannes,

On Wed, 2005-04-13 at 11:56 +0200, Hannes Wallnoefer wrote:
> Yes, I'd consider this a bug. An extension mechanism that could
> otherwise be very popular with GCJ is to compile an application's core
> classes to native code, and allow extensions to be loaded from
> jar/class files by adding them to the classpath and setting a property
> somewhere, using a simple Class.forName() internally. I know it is
> possible to do this using a custom class loader, but many apps just do
> it the simple way, and rightly so.
> 
> Consider the typical case of a JDBC driver, which is registered and
> loaded by adding it to the classpath and doing a Class.forName() in
> the app code. Isn't it a pretty massive constraint if this doesn't
> work between a native app and a jared/class-compiled driver?

Yes. And a lot of people worked really hard to make that as transparent
as possible even for programs that were not designed for gcj:
http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
http://developer.classpath.org/mediation/ClasspathShowcase
In summary if you have a program designed for the traditional java
platform then GCJ 4 will make it really easy/transparent to have the
behavior you describe above without needing to make any changes to your
program source code.

But it is indeed painful (a bug!) that programs, like kawa, originally
designed for gcj and not using the new BC ABI have it harder and cannot
use Class.forName() as they expected. If I had a quick fix I would fix
it immediately. But we are very close to the release so need to be a bit
careful. Problem is that the class loader infrastructure has been really
cleaned up and behaves exactly like traditional java platforms now
(including extension class loaders, endorsed dirs, etc.) This makes some
of the original hacks for class loading with old native gcj designed
programs more difficult/wrong.

- It is a bug that getClassLoader() and getInternalClassLoader() return
something different.
- That the bootstrap classloader (null) only loads the bootstrap classes
is correct. It was a bug that it loaded byte code .class files in past
releases.
- The real bug/design misfeature is that compiled in classes have a null
classloader.

Quickly fixing that last point for 4.0 is tricky (at least for me).
Maybe the correct hack for now is to add the same hack to
Class.forName() as we now use in getClassLoaderLoader(). So we do use
the system class loader for compiled in classes in traditional gcj
native applications. But that would need careful testing. I am afraid we
might break something else.

Cheers,

Mark

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