JAR hell is a term similar to DLL hell used
to describe all the various ways in which the classloading process can end up
not working. Three ways JAR hell can occur are:
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.
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.
No comments:
Post a Comment