The duplicate class registration problem

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

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.

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?

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.

regards

Bryce.

Torsten wrote:

>> Duplicate class registration. Obviously we need to improve the error 
>> behaviour here, since an exception can't be thrown at this point due 
>> to recent changes in libgcj.
>
>
> So, I find this is a real issue. Just that single debug line helps 
> enormously. Please put it in the distribution.
>
> And as another point, the w3c classes should _not be in the standard 
> library. That's only done in java 1.4 and ok there, because you can 
> still have your own by putting them in the classpath before the sun 
> ones. Believe be this is an issue when working with several xml 
> packages. Sometimes I even had to manually edit decompiled code just 
> to get all classes in the classpath work with the w3c version I found 
> to work.
>
> My suggestion is to have a seperate library. libxml or libw3c. And the 
> minnimum that you should really do is _document_ that those classes 
> are there.
>
> So, thanks. Now my program starts up (jiipie) and I can debug