This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: GCJ not using java.lang.Exception in libgcj.jar??
- To: "Kevin A. Burton" <burton at relativity dot yi dot org>
- Subject: Re: GCJ not using java.lang.Exception in libgcj.jar??
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Sun, 28 Jan 2001 12:41:00 +1300
- CC: java-discuss at sources dot redhat dot com
- References: <m3d7d8vrqn.fsf@relativity.yi.org>
"Kevin A. Burton" wrote:
> Could this be the problem? java.lang.Exception under GCJ is native and
> contained in libgcj.so? If so this is strange... I can't see any advantage to
> doing this and I think it might be a Bad Thing. There might be a speed
> advantage!?
All classes in libgcj are compiled as native and included in libgcj.so. That is pretty
much the whole point.
Think of all native classes as being loaded by the same "system" classloader, and think of
bytecode classes as being run by a different, interpreter class loader. If a class is
compiled against a java.lang.Exception, you can not then replace the java.lang.Exception
with a different, bytecode version. Different classes with the same name could exist in
different classloaders, but would not be cross-assignable.
So, basically you need to copy your modified class into the libgcj source tree and rebuild
libgcj.so as well as libgcj.jar.
regards
[ bryce ]