|
The [[OSGi]] Alliance specified (starting as JSR 8 in 1998) a modularity framework that aims to solve JAR hell for current and future VMs 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.
}}</ref> which was included in [[Java version history#Java SE 9|Java 9]] . Releasedintroduced the [[Java Platform Module System]] in 2017 ,. itThis includesspecifies supporta distribution format for modularcollections softwareof Java code and associated resources. It also specifies a repository for storing these collections, termedor "Java''[[Modular Platformprogramming|modules]]'', Moduleand System"identifies how they can be discovered, whichloaded isand controlledchecked onfor sourceintegrity. levelIt includes features such as namespaces with module-info.javathe aim of fixing some of the shortcomings in the existing [[JAR (file format)|JAR]] filesformat. ItThe Java Platform Module System follows a different philosophy from the OSGi architecture that aims at providing modularity for the Java Runtime Environment in a backwards-compatible way that uses the default mechanism of loading classes that the JRE provides. However, since itthe Java Platform Module System does not offer the ability for controlled co-existence of libraries with different versions, it isdoes not suited forfully tacklingaddress the JAR hell problem.<ref>{{cite web|first1=Neil|last1=Bartlett|first2=Kai|last2=Hackbarth|title=Java 9, OSGi and the Future of Modularity (Part 1) ▼To remedy the JAR hell problems, a [[Java Community Process]] – JSR 277 was initiated in 2005. The resolution – [[Java Platform Module System]] — intended to introduce a new distribution format, a 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>{{cite web
|url=https://blogs.oracle.com/mr/entry/jigsaw
|title=Project Jigsaw
|publisher=[[Oracle Corporation]]
|author=Mark Reinhold
|date=2010-09-20 |df=mdy
|archive-url=https://web.archive.org/web/20151208171951/https://blogs.oracle.com/mr/entry/jigsaw
|archive-date=2015-12-08
|url-status=dead
}}</ref> The Java Module System was later rebooted as "project Jigsaw"<ref>{{cite web
|url=http://openjdk.java.net/projects/jigsaw/
|title=Project Jigsaw
|publisher=[[Oracle Corporation]]
|accessdate=2015-11-29
▲}}</ref> which was included in [[Java version history#Java SE 9|Java 9]]. Released in 2017, it includes support for modular software, termed "Java Platform Module System", which is controlled on source level with module-info.java files. It follows a different philosophy from the OSGi architecture that aims at providing modularity for the Java Runtime Environment in a backwards-compatible way that uses the default mechanism of loading classes that the JRE provides. However, since it does not offer the ability for controlled co-existence of libraries with different versions, it is not suited for tackling the JAR hell problem.<ref>{{cite web|first1=Neil|last1=Bartlett|first2=Kai|last2=Hackbarth|title=Java 9, OSGi and the Future of Modularity (Part 1)
|url=https://www.infoq.com/articles/java9-osgi-future-modularity/#1|publisher=InfoQ|date=2016-09-22}}</ref>
| 