Class Equality In Checking Loader Constraint

Question

Hi,
Class loaders are suppose to throw constraint violation (Linkage Error) if a class with the same name is loaded by two separate class loaders if the class being loaded are not the same class. How is this equality of classes checked for? Does it have to come from the same location (jar file) or does it merely have to be the 'same'. If it is the latter, how is the equality determined.
We have run into a strange situation where org.w3c.dom classes are loaded from jre 1.4 runtime (rt.jar) by the web server but then these classes also exist in our web applications WEB-INF/lib and get loaded by web application context classloader. We have tried a couple of versions of jars that contain the org.w3c.dom classes in the WEB-INF/lib directory and one of them causes a constraint violation while the other one does not. When we looked specifically at the class (Node.class) that is causing the constriant violation, the strange thing is that the version which causes the constraint violation contains the same stuff (same after decompilation) as the one in rt.jar while the one which didn't cause constraint violation actually had more methods. We are pretty confused as to how the loader is checking the constraint. Can some one shed some light on what is happening?
Regards,
Len Takeuchi

Answer 1

Hi,
Class loaders are suppose to throw constraint
violation (Linkage Error) if a class with the same
name is loaded by two separate class loaders if the
class being loaded are not the same class. Huh?
What does "same name" mean. The fully qualified name? It certainly has nothing to do with the name of the class itself.
And what do you mean by "are not the same class"? That is definitely not the case if the functionality is different. Hotloading works and it would be pointless if the functionality and even the interface couldn't change.
>
We have run into a strange situation where
org.w3c.dom classes are loaded from jre 1.4 runtime
(rt.jar) by the web server but then these classes
also exist in our web applications WEB-INF/lib and
get loaded by web application context classloader.It sounds to me like you have a class loaded by the system class loader and one loaded by a custom class loader.
That has nothing to do with the problem above though.
The ideal solution is for you to not do that. Other than that I believe (but I could be wrong) that you can implement a custom class loader which does NOT try to resolve to the parent. This means that you must write it yourself. The url one in the java API will not work.
We have tried a couple of versions of jars that
t contain the org.w3c.dom classes in the WEB-INF/lib
directory and one of them causes a constraint
violation while the other one does not. When we
looked specifically at the class (Node.class) that is
causing the constriant violation, the strange thing
is that the version which causes the constraint
violation contains the same stuff (same after
decompilation) as the one in rt.jar while the one
which didn't cause constraint violation actually had
more methods. We are pretty confused as to how the
loader is checking the constraint. Can some one shed
some light on what is happening?
It isn't calling the class that you think it is.
If you search this site there are examples of code that allows you to determine exactly where a class is loaded from.