Bug ID: JDK-4972409 cryptic error message: LinkageError [classname] violates loader constraints

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6 b93Fixed

When two classes of the same name are loaded inconsistently, the VM issues the above LinkageError, but the error message is very cryptic.

At the very least it can refer to the VM spec section 5.3.4. Furthermore, it should provide more information (such as (a) which class loader tried to load the 2nd class, (b) which class loader loaded the original definition, (c) where those two classes are being loaded from.)
Also, if I'm not mistaken, the error message could be further improved to indicate exactly which
constraint is violated.

All of those information makes it easier for developers to track down the problem. If you search
Google with "LinkageError loader constraints", you'll see how developers out there are hopelessly
confused with this error.

Finally, the definition of the loader constraints in the VM spec is hard to understand for most of the people. Perhaps it could be clarified in somewhere?

###@###.### 2003-12-23

EVALUATION Note that there are now 6 different circumstances where loader constraint violations are identified: 1. Resolving the types in a method 2. Resolving the types in an interface method 3. Resolving the types in an overriding method 4. Resolving the types in a method during interface itable initialization 5. Resolving a field 6. The loader has previously initiated loading for a different type with the same name
19-07-2006
EVALUATION All the information that the requestor asks for is not readily available at the time that a constraint is violated, but we can at least provide information in the error message as to the general context in which the violation was detected, and the class loaders involved (though only by type as classloaders are not named and so different instances can't be distinguished. For example: java.lang.LinkageError: loader constraint violation: in resolving method "B.getA()LA;" the class loader (instance of sun/misc/Launcher$AppClassLoader) of the current class, C, and the class loader (instance of Loader) for interface I have different Class objects for the type A used in the signature We are also looking at providing additional diagnostic "trace messages" to show when loader constraints are added, extended or removed. Together these will allow the developer to more easily track down class loading problems.
14-06-2006
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon
08-09-2004
EVALUATION Providing more information in the error messages will require some code reorganization as the error string is currently a simple const char* which is passed back to a calling routine -- the calling routine throws the LinkageError. We'll need to malloc a string and arrange to free it if the error needs to be thrown. Also, we'll need to record some more information to be more specific in the message. I'll commit this bug to 1.5.1; we're too late in the 1.5.0 development cycle to consider for this release. However, I will update the current static strings in the error messages to refer to the VM spec section. ###@###.### 2004-01-21
21-01-2004

Relates :	JDK-6942092 - Loader-constraint test is failing against 1.5.0u24b06-hsx
Relates :	JDK-6728025 - LinkResolver is missing some ResourceMarks