Java class loader: Difference between revisions

Revision as of 12:43, 19 April 2011

Revision as of 19:54, 28 April 2011

Line 77:

* The first case is when a developer or deployer of a Java application has accidentally made two different versions of a library available to the system. This will not be considered an error by the system. Rather, the system will load classes from one or the other library. Adding the new library to the list of available libraries instead of replacing it, may see the application still behaving as though the old library is in use, which it may well be.

* Another version of the problem arises when two libraries (or a library and the application) require different versions*** of the same third library. If both versions of the third library use the same class names, there is no way to load both versions of the third library with the same classloader.

* The most complex JAR hell problems arise in circumstances that take advantage of the full complexity of the classloading system. A Java program is not required to use only a single "flat" classloader, but instead may be composed of several (potentially very many) nested, cooperating classloaders. Classes loaded by different classloaders may interact in complex ways not fully comprehended by a developer, leading to inexplicable errors or bugs{{Citation needed|date=January 2011}}.