This is the mail archive of the
mailing list for the Java project.
Re: GCJ not using java.lang.Exception in libgcj.jar??
- To: burton at relativity dot yi dot org (Kevin A. Burton)
- Subject: Re: GCJ not using java.lang.Exception in libgcj.jar??
- From: Tom Tromey <tromey at redhat dot com>
- Date: 27 Jan 2001 13:02:06 -0700
- Cc: java-discuss at sources dot redhat dot com
- References: <firstname.lastname@example.org>
- Reply-To: tromey at redhat dot com
>>>>> "Kevin" == Kevin A Burton <email@example.com> writes:
Kevin> If you look at the UML on the website you can see visually how
Kevin> JavaCore installs into the JVM. Basically it replace
Kevin> java.lang.Exception with its own version.
When you do this with the JVM I assume you have to edit their `rt.jar'
or whatever it is called. Right?
Kevin> Basically this means that java.lang.Exception is not getting
Kevin> instantiated as bytecode but instead is native... correct?
Yes. The entire runtime and all the default class libraries are
compiled, not interpreted. We install the class files because the
compiler needs to read them in order to compile other Java programs.
Kevin> Could this be the problem? java.lang.Exception under GCJ is
Kevin> native and contained in libgcj.so? If so this is strange... I
Kevin> can't see any advantage to doing this and I think it might be a
Kevin> Bad Thing. There might be a speed advantage!?
I doubt there is a noticeable speed advantage for Exception. However,
I don't see how having this class be compiled could be considered a
`Bad Thing'. I think what you're trying to do isn't really guaranteed
to work. Also, libgcj is primarily a compiled Java environment. So
compiling Exception is in line with our goals.
Why do you need to reimplement Exception, anyway? That seems weird.