This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: FYI: loading a class twice
- To: minyard at acm dot org
- Subject: Re: Patch: FYI: loading a class twice
- From: Jeff Sturm <jsturm at one-point dot com>
- Date: Wed, 5 Sep 2001 21:34:44 -0400 (EDT)
- cc: tromey at redhat dot com, Java Patch List <java-patches at gcc dot gnu dot org>
On 5 Sep 2001 minyard@acm.org wrote:
> Tom Tromey <tromey@redhat.com> writes:
>
> > I'm checking this in. This is a reworked version of a patch from
> > Corey Minyard. I changed his patch to throw an error instead of
> > printing a message to stderr. This seems more correct to me.
>
> Won't throwing an exception leave the system in a "half-baked" state?
> That might not be good. I agree that printing the message is not
> optimal, but it might be better to pre-check the whole thing and
> refuse the whole object if you find a problem. I hadn't really
> thought about it until now (it was just a quick hack), but it might be
> better to go up a level, grab a lock, and do a scan for problems then
> install all the classes.
I had thought libgcj could quietly discard the duplicate class
registration. I'm not crazy about either printing a message or throwing
an exception, frankly... one should be able to override a class in
libgcj.so (or any other DSO) by placing it earlier in the link order.
Then ELF dynamic linking semantics ensure only the first copy is visible,
even during class registration.
Jeff