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: Jeff Sturm <jsturm at one-point dot com>
- Subject: Re: Patch: FYI: loading a class twice
- From: minyard at acm dot org
- Date: 07 Sep 2001 16:09:26 -0500
- Cc: tromey at redhat dot com, Java Patch List <java-patches at gcc dot gnu dot org>
- References: <Pine.LNX.4.10.10109071656280.21361-100000@mars.deadcafe.org>
- Reply-To: minyard at acm dot org
Jeff Sturm <jsturm@one-point.com> writes:
> On 6 Sep 2001 minyard@acm.org wrote:
> > But I still don't think it's a good idea to silently use the first
> > version of a class in the load order.
>
> Let me try to be clear. I think an attempt to load two identical classes
> (equal pointers) can be safely ignored.
>
> However an attempt to load two different classes with the same name can
> lead to problems. In this case I would consider it acceptable to print a
> message and abort.
>
> The first scenario is much more likely on ELF targets. Even symbols in
> the .jcr section of an object will be resolved by searching all libraries
> in order. However that behavior is certainly platform dependent.
>
> If I understand the patch correctly, we only check the former, not the
> latter. The latter is more dangerous IMO.
The patch will throw an exception on both, I believe. I believe the
class name is the thing used to resolve the symbol in question. Since
the symbol name is the same in both versions, and the loader will
always resolve to the older one, that's how the symbol get put into
the table twice.
However, since only the class name is used to resolve the symbol name,
two classes with the same name will cause this, even if they are
completely different classes (unlikely), or different versions of the
same class (much more likely).
As part of this, if you could get the new class information you could
scan the class information and compare it to the old one to see if it
differed. But I'm not sure how you would get the new class
information. But if you could verify that they were exactly the same
(same methods, same values for constants, every method the same size),
it would make sense to just ignore the second one, and if they were
not, it would make sense to refuse to load the second one somehow, or
abort.
-Corey