Java class loader: Difference between revisions

Revision as of 02:53, 20 February 2011

Revision as of 17:11, 22 February 2011

Line 79:

* 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 (or,potentially invery fact, an indefinite number ofmany) 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}}.

The [[OSGi]] Alliance specified (starting as JSR 8 in 1998) a modularity framework that solved JAR hell for current and future VMs both in ME, SE, and EE that is widely adopted. Using metadata in the JAR [[manifest file|manifest]], JAR files (called bundles) are wired on a per-package basis. Bundles can export packages, import packages and keep packages private, providing the basic constructs of modularity and versioned dependency management.