IBM released the final version of the JSR 291, Dynamic Component Support for Java SE specification and reference implementation. JSR 291 closely mirrors the broader OSGi (Open Services Gateway Initiative) specification with the aim to:

Enable components to be declared through metadata and be assembled at runtime using a class loader delegation network. The specification ... also allow[s] components to be dynamically life cycle managed (install, start, stop, update, uninstall).

Indeed, JSR 291 is effectively a version of the OSGi Service Platform Core Specification, for Java SE. JSR 291 is expected to become a standard part of Java SE 7.

On the need to define a uniform way to build modular Java applications, the JSR 291 spec notes that:

The need for a dynamic component model and lifecycle is well understood by several communities. These include the OSGi community, the Eclipse Community and the Apache Community who are all addressing this requirement in the same manner. This capability has already been brought into the Java community via JSR 232 for the Java ME (CDC) domain.

Currently, the needs of modular application development are addressed by two JSRs: in addition to JSR 291, JSR 277, Java Module System, also aims to address this area, albeit from a different angle.

JSR 291 spec lead Glyn Normington compared the two specifications in a blog post earlier this summer, Comparison of JSR 277 and JSR 291 features. Normington noted the large degree of overlap between the two specs, but also the significant differences, such as JSR 291's support for dynamic component lifecycle, a crucial feature for set-top boxes and other devices expected to dynamically download and execute service components. The JSR 291 spec describes this dynamic download and lifecycle feature:

OSGi-compliant devices can download and install OSGi bundles, and remove them when they are no longer required. The Framework manages the installation and update of bundles in an OSGi environment in a dynamic and scalable fashion. To achieve this, it manages the dependencies between bundles and services in detail.

Finally, some in the Java, and especially in the Jini, community felt that neither JSR 291 nor JSR 277 builds on many years' of experience with composing dynamic systems out of existing Java components, especially of network-bound components. In his Artima blog, Jini and OSGi, yet again, Jini architect Jim Waldo addressed this issue, noting the different types of service composition Jini, on the one hand, and OSGi and JSR 291 on the other, address:

OSGi and Jini are service architectures built for completely different contexts. OSGi is a service architecture for services that are in the same address space. It allows you to build programs out of cooperating services. And for that sort of thing, it is pretty good.

Jini is a service architecture for distributed systems that are built out of services that are separated by a network. And the network is a very different environment from the single virtual machine

What do you think of JSRs 291 and 277?