Java class loader: Difference between revisions

Revision as of 00:29, 4 December 2006

Revision as of 04:18, 4 December 2006

Line 10:

{{{category|[[Category:Articles for deletion]]}}}

<!-- End of AfD message, feel free to edit beyond this point -->

'''Jar Hell''' arises in the [[Software development|development]] and deployment of [[computer programsprogram]]s written in the [[Java language]].

Computer programs often make use of "[[software libraries"]]. A library is a collection of more or less related [[code]]. The program may make use of external or [[third party library|third party libraries]] (that is, libraries written and provided by someone other than the author of the program) or may itself be composed, at least in part, by a number of libraries.

In the Java language, libraries are typically packaged in so-called [[jar-file|Jar files]]. Libraries can contain various different sorts of objects, but for the purposes of this article the most important type of object contained in a Jar file is a [[Java "class"]]. A class can be thought of as a named unit of code. The [[Java runtime system]] is responsible for locating libraries, reading their contents, and [[class loader|loading the classes]] contained within the libraries. This loading is typically done "on demand", in that it does not occur until the class is actually used by the program.

This "classloading" process is actually fairly complicated, and is the subject of much confusion. For our purposes here, the important fact is this: that a class with a given name can only be loaded '''once''' by a given [[classloader]].

== Malfunction ==

Enter "''Jar hell"'', which is actually a more or less general term used to describe all the various ways in which the classloading process can end up frustratingnot expectationsworking.

The* simplestOne case to understand is when a developer or deployer of a [[Java application]] has accidentally made two different versions of a library available to the system. This is not considered an [[error|error]] by the system. Rather, the system will load classes from one or the other library. So, a developer who thinks she has replaced a library with a new version, but who has instead simply added the new library to the list of available libraries, may be surprised to see the application still behaving as though the old library is in use, which of course, 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. Without taking extraordinary measures (which may or may not even be available, depending on the circumstances) there is no way to load both versions of the third library.

* 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 (an indefinite number, in fact) nested, cooperating classloaders. This is not as uncommon as one might think: so-called "[[servlet]] containers" are typically implemented in terms of multiple classloaders. The interactions between classloaders is too complex to be fully described here. It is sufficient to say that classes loaded by different classloaders interact in ways which may not be fully comprehended by the developer, leading to inexplicable errors or bugs.

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 (an indefinite number, in fact) nested, cooperating classloaders. This is not as uncommon as one might think: so-called "servlet containers" are typically implemented in terms of multiple classloaders. The interactions between classloaders is too complex to be fully described here. It is sufficient to say that classes loaded by different classloaders interact in ways which may not be fully comprehended by the developer, leading to inexplicable errors or bugs.

== See also ==

*[[Apache Maven]], automated software build tool with dependency management

*[http://www.jayasoft.org/ivy, Dependency manager], now at Apache incubator: [http://incubator.apache.org/projects/ivy.html]

[[Category:Java programming language]]

[[Category:Anti-patterns]]