Thanks for the comments. I think it seemed like the OSGi JSRs have been approved rather quickly. As for the competing with the other JSRs, it does indeed do that specifically because much of the community believes OSGi superior. I don’t get into that debate.

Furthermore, 277 and 294 were formalized declarations of Sun’s intent to solve the problems. Gilad and others will probably tell you they came up with the ideas years if not a decade ago. I still feel as though this particular JSR was specifically put through and rather quickly at that because Sun was looking to formalize some of the more academic discussion it had been having into JSRs. Whether or not that is accurate is left to the historians. Just seemed that way.

As for OSGI, I understand the nature of OSGi and how it solves the modules, lifecycle and dependencies as well as distribution. My point was that there is more to making large distributed applications than those concerns. You have availability, provisioning and other concerns as well. OSGi can’t solve these problems until the JVM does because it isn’t necessarily allowed to modify the JVM semantics or the runtime. The different with the Sun JSRs like 277 and 294 is that they more than likely will modify the JVM because Sun is driving them. Therefore, they have the potential to create a truly modular system, which undoubtedly OSGi will take advantage of.

Also, OSGi doesn’t just address services. It addresses modules, security and lifecycle, all on top of the existing class loader architecture/structure. Services are part of that process, but it’s a superset of the functionality of 277 and 294 as well as other parts.

As for the distributed applications or mini apps; there’s nothing to stop that happening in an OSGi platform, but that’s not what it sets out to achieve. In addition, there’s no reason that the services need to be local to one VM as distributed frameworks like R-OSGi and Newton and Infiniflow show.

In terms of restarts, OSGi provides exactly the same mechanism as Tomcat does for webapps; you can stop, restart, install and uninstall on the fly. The fact that you’re always in one VM means that there are some situations (e.g. badly behaved native code) that can take the process down as well as memory management; but that’s a deployment choice that you’ve got. There’s no reason that that can’t exist using the same framework as you do for modules.