The rising popularity of modular, polyglot application stacks has restarted a conversation at the OSGi Alliance about providing a language and run-time neutral version of the standard. The overall aim would be to allow a wide variety of languages to participate in an OSGi system without the component parts needing to be implemented in the same language or runtime environment as the other bundles. RFP-159 and RFP-156 have been proposed to address the OSGi standardization for JavaScript and native C/C++ implementations respectively.
Polyglot OSGi was originally introduced on the OSGi mailing list in 2007 as "Universal OSGi", though there are some indications that the conversation about multi-language support started as far back 1999. Universal OSGi, designated by the alliance as RFP-89, was a broad-scoped proposal that intended to address common concerns of modularity from the standpoint of all languages.
The success of JavaScript in recent years as both a server and client programming language has led the JavaScript community to start addressing problems of modularity that the language poses. Package managers, such as NPM (Node Package Manager), have arisen to garner the benefits of modularity in a language that otherwise does not provide native support for packaging and modularity.
Through RFP-159, the OSGi Alliance hopes to unravel the many homebrewed modularity solutions prevalent in JavaScript, by making the language a first-class target for the OSGi "register, find, bind" service model concepts. The Eclipse Orion project paved the way for standardized JavaScript OSGi through the development of a so-called "microservice" implementation that provided cross-language OSGi support within a browser-based implementation of the popular IDE.
Section 4.3 of the OSGi Microservices RFP notes that a main motivator for OSGi interoperability with JavaScript is that many companies have significant investment in Java, and decoupling the service implementation affords a greater possibility for reuse of existing code. The section closes by noting an example where a company may want to implement a service in Node.js, without having to change the way that their legacy Java code makes use of that service.
JavaScript isn't the only language, beyond Java, that the OSGi Alliance is targeting. As a subset of the broader "Universal OSGi", RFP-156 was formally introduced to address the need for the OSGi service model in native language implementations -- specifically C and C++. That RFP's conversation is being driven by participating projects, such as nOStrum and Apache Celix, that have already gone to lengths to implement OSGi concepts on their own.
While the JavaScript OSGi Microservices RFP makes a point to garner the benefits of Java interoperability, the Native OSGi RFP's "Problem Description" section makes a point to narrow the conversation of Native OSGi to "focus solely on the Core Specification." It also points out that, while utilizing the OSGi layer to make use of Java services from legacy native code should be possible, the same "interoperability with Java bundles can be achieved using remote services," and therefore is not a primary focus of the proposal.
The concepts supporting both RFP-159 and RFP-156 have been around for over a decade, but the formal process of focusing the broader discussion of Universal OSGi into targeted conversations for different languages is comparatively in its infancy. Both RFP-159 and RFP-156 were authored in just April of this year, and their presence on the OSGi Alliance's bugzilla tracker was made public in June.