Re: The duplicate class registration problem

[Corey Minyard <minyard at acm dot org>]

This is a very difficult issue, and we have talked about it before.  I 
can see two "right" ways to do it:

* Only use the first version loaded, which should be pretty easy to do. 
 The code that I put in before (except I had a print, the GCJ 
maintainers substituted an exception) could be used, but just have it do 
nothing on a duplicate class.  This is how a standard JVM works, except 
in this case if you use methods that are only in the second class, not 
the first, really wierd things will happen.  A JVM will just fail.  But 
this leads to many wierd problems when using different pieces that have 
different versions of the same component.  This happens in JVM land 
quite often.

* Do a two-stage load of a class file, the first scans for errors and 
the second actually installs everything.  You could probably raise an 
exception in this case, since it's at a higher level and doesn't leave 
the initialization half-baked.  But the load is still half-baked; the 
symbols are in the ELF symbol table, but not in the GCJ class tables.

Any other ideas?  I really don't like either option.  You could do the 
first option and have some flag you could set to cause GCJ to print and 
abort if it detects a problem.  That's the best I can come up with.

-Corey

Bryce McKinlay wrote:

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