Java class loader: Difference between revisions

Revision as of 20:56, 18 March 2011

Revision as of 10:12, 19 March 2011

Line 81:

* 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}}.

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.

To '''remedy the JAR hell''' problems a [[Java Community Process]] — JSR 277 was initiated in 2005. The resolution — [[Java Module System]] — intended to introduce a new distribution format, modules versioning scheme and a common modules repository (similar in purpose to [[Microsoft .NET]]'s [[Global Assembly Cache]]). In December 2008 Sun announced that JSR 277 was put on hold.<ref>http://www.osgi.org/News/20081217</ref>