Re: [Fwd: Re: The duplicate class registration problem]

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

Dave wrote:

> 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. 


Right. Thats not possible given the current linking model. You just 
can't have two different classes with the same name under GCJ, if both 
classes came from compiled code. If you do, assuming ELF at least, the 
first one loaded (ie the one in you main program or the first one found 
in shared libraries) will hide subsequent definitions. Of course, given 
classes loaded from bytecode, libgcj can work exactly the same as the JDK...

Now, with the JDK, you could specify your own definition of a class 
ahead of the core classes on the classpath, and this definition would 
override the JDK's. Of course you're asking for trouble if the 
implementations are different and other parts of the JDK's classes 
depend on them. But in GCJ, the problems are likely to be worse and less 
deterministic - for example, say you "replaced" a class with an older 
version that removes a few static methods, and some other class in 
libgcj (which you didn't replace) happens to depend on some of the 
methods you removed. With the JDK, you'd get an 
IncompatibleClassChangeError or some such. But with GCJ, the code in 
libgcj will continue to "see" its own implementation of those 
un-replaced methods, yet see/use the old, replaced implementations of 
the other methods.

Also, this behaviour assumes ELF semantics. Other systems like Windows 
probibly behave completely differently...

> 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?  

> Short term, it'd likely be best to report some kind of Error when GCJ
> happens across many of these problems.  


Yes. This is what we do now, but as Torsten pointed out, it means that 
its hard to run some applications on GCJ.

>> 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 wasn't suggesting that libgcj shouldn't include XML support, but 
rather the XML stuff go into a separate .so file. When GCJ sees that you 
are using a class from the .so, it would link against the libgcjxml.so 
or whatever, but wouldn't otherwise. This solves the problem, but not 
really in a general way, and falls down if anything in the "core" 
libgcj.so ever needs to use something in the XML .so. Also, the compiler 
can't detect dynamic references (forName) to classes in these other 
.so's, so in that case you'd have to link them manually if they were 
needed.

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


You'd have to change the linking model.

regards

Bryce.