[Fwd: Re: The duplicate class registration problem]

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

-------- Original Message --------
Return-Path: <david-b@pacbell.net>
Received: from snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by 
waitaki.otago.ac.nz (8.11.2/8.11.2) with ESMTP id f9OKh0W28633 for 
<bryce@waitaki.otago.ac.nz>; Thu, 25 Oct 2001 09:43:01 +1300
Received: from pacbell.net ([206.170.7.48]) by mta6.snfc21.pbi.net 
(iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id 
<0GLQ00L7K9FR9S@mta6.snfc21.pbi.net> for bryce@waitaki.otago.ac.nz; Wed, 
24 Oct 2001 13:40:41 -0700 (PDT)
Date: Wed, 24 Oct 2001 13:42:00 -0700
From: David Brownell <david-b@pacbell.net>
Subject: Re: The duplicate class registration problem
Sender: mojo@nodots-daemon
To: bryce@waitaki.otago.ac.nz, minyard@acm.org
Message-id: <3BD72798.989A6BCC@pacbell.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-test11-pre5c i586)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <1003825061.27940.ezmlm@gcc.gnu.org>



[ private reply purely because my ISP currently gets rejected by the
  list agent, feel free to forward to the java list ... ]

> Subject: The duplicate class registration problem
> Date: Tue, 23 Oct 2001 12:52:54 +1300
> From: Bryce McKinlay 
> To: java@gcc.gnu.org
> 
> Torsten Rueger raised an important issue in a private email, relating to
> duplicate classes. What happens when an application wants to use its own
> version of some (say, javax.*) package, but that package is also
> included in libgcj? Currently, of course, we don't allow duplicate class
> registration at all - but I can only imagine that the problem is going
> to get worse as libgcj includes more classes.

How close is the GCJ class loading behavior to what JDK 1.2 specifies?

It's my understanding that the very notion of "duplicate classes" is
a violation of Java semantics.  Classes are the same if they have the
same name and ClassLoader ... otherwise they are different, even when
they have the same name.  "Different" classes could be different versions
of the same API, or just ones linked differently.


> This could be addressed if we move towards some sort of weaker linking
> model in the future (that better matches the semantics of the java
> classloading), but what to do in the short term?

Could someone summarize the behavior of the current class loader in GCJ?
Including how it differs from what JDK 1.2 (and later) specifies.  Can
version mismatches be detected somehow?  I'm not very interested in how
well the security policy stuff is supported, just the linking semantics.

Short term, it'd likely be best to report some kind of Error when GCJ
happens across many of these problems.  Applications do depend on the
standard behavior, and it's not good if GCJ silently does something else.


> One fix/workaround might be split things like the (eg) xml classes into
> separate shared libraries, but this doesn't help if another part of
> libgcj ever needs to use those classes internally - perhaps we can just
> avoid that though.

I happen to think that libgcj _should_ include XML support, and ideally
the ClasspathX version (http://www.gnu.org/software/classpathx/jaxp/).
There are some JDK classes that rely on XML, so libgcj can't avoid the
problem.

I'd rather see some discussion on how to make GCJ behave more like the
JDK 1.latest class loading definition says.

- Dave