Today OSGi is central to Eclipse, he said. "It is the base run-time for Eclipse. Every time you see someone running Eclipse you are seeing someone running Equinox, our OSGi framework implementation," he said. "That means OSGi is on millions of developer desktops and in millions more RCP applications. IBM has adopted Equinox as the base run-time for WebSphere Application Server 6.1. BEA is reportedly taking a similar path." McAffer said he is particularly interested in new work just starting in the area of provisioning. The Eclipse Update Manager has served well as the mainstay for provisioning Eclipse-based systems, he said. "However, the world has evolved around Update Manager with the move to OSGi, Eclipse as an RCP, server-side Eclipse, dynamic behaviors, etc.," he said. "It is time for a review and rework. To facilitate that effort we have started an Equinox incubator work area for provisioning and have been discussing participation with various teams and companies."The U.S. Army, meanwhile, is using OSGi as the run-time on which its Cyrano software for helping to find weapons of mass destruction is based. And Adobe Systems has used OSGi as the underlying technology in its Version Cue embedded client/server tool set. However, despite the widespread adoption of OSGi, there is controversy. Sun Microsystems was a founding member of the OSGi Alliance in 1999, even granting the organization the power to set Java standardsa capability typically held by the JCP (Java Community Process). Yet, now Sun has instituted a JSR (Java Specification Request) known as JSR 277 that is aimed at creating a new component model for Java 7. JSR 277 competes with JSR 291, the OSGi specification. In a blog post from October, Peter Kriens of the OSGi Alliance wrote: "JSR 277 takes a simplistic view of the world, ignoring many real life problems: consistency, optionality, split packages, etc." Moreover, he said, "I do not doubt that this specification will end up in Java 7, but it will further fragment the Java world for no technical reason. Not only is this specification impossible to implement on J2ME [Java 2 Micro Edition] any time soon, it will also leave the many OSGi adopters out in the cold." Paremus Nicholson said that OSGi, currently going through JSR 291, "already exists, is mature and works well. So splitting the standard by introducing a whole new approach in JSR 277 wont, in our opinion, help anybody and probably wont succeed given the other big JVM producersIBM, BEA and soon Apacheare active supporters of OSGi and the OSGi Alliances Enterprise Expert Group." And OSGi can also run on a wide range of Java environments, including the stripped-down JVMs in mobile phones and devices and earlier JVM versions, Nicholson said. JSR 277 will only work on future JVM versions, "so were talking some way off, maybe three to five years, for adoption, by which time OSGi will be everywhere," Nicholson said. "On the other hand, JSR 277 could help if it focuses on adding JVM-level support for OSGi and by factoring the JVM libraries into OSGi bundlesmost of them currently ship in a huge monolithic jarlike Harmony, Apaches JVM project." Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
The work area has been seeded with some initial implementations of OSGi deployment-related specifications as well as some prototype code the Equinox team developed, McAffer said. "We are seeking to push beyond the current OSGi and Update Manager approaches and create a provisioning framework for Eclipse and OSGi-based systems," he said. "This framework would then be used to address the wildly different provisioning scenarios that seem to naturally occur in enterprises today. Coincidentally OSGi has started an Enterprise Expert Group, and we look forward to working there to create and implement applicable standards."