The OSGi component framework has evolved over many years, expanding from an embedded systems standard to finally encompass Java enterprise servers. With last year's formal roll-out of OSGi Enterprise Specification Release 4, Version 4.2, it has found wider use. At the same time, OSGi has retained a reputation as a complex technology, more for systems programmers than mainstream application developers.Many individuals encounter OSGi in the form of Eclipse standards. "The Eclipse Gemini and Eclipse Virgo projects have matured and have started to actually ship,'' Eclipse Foundation Executive Director Mike Milinkovich told SearchSOA.com at last week's EclipseCon 2011 event in Santa Clara, Calif.
"Gemini provides most of the reference implementations for the OSGi enterprise expert group. Virgo, which used to be the SpringSource DM server, is starting to ship now and what that does is extend Equinox [OSGi R4 core framework specification] with Spring, providing manageability and software lifecycle [capabilities].
Modularity is OSGi's stock and trade, allowing Java EE components to be plugged in and pulled out with greater ease, thus increasing the manageability of Java applications.
OSGi has been popular with vendors of application servers, who employ plenty of advanced Java programmers. But improvements in the next OSGi release do not necessarily solve complexity issues for mainstream developers who may find themselves coding against it.
The OSGi module scheme centers on the concept of "bundles" that associate Java classes with an explanatory manifest. The next release of OSGi focuses on improvements in bundle aggregation.
In the next OSGi rev, a former composite bundle model has been replaced by a resolver hook model, according to BJ Hargrave, CTO of the OSGi Alliance, committer on the Eclipse Equinox project and senior technical staff member at IBM.
"We have whittled it down to the basics," Hargrave told attendees at EclipseCon 2011. But resolver hooks are powerful methods that do not simplify the work of the typical developer.
"It's another chance to shoot yourself in the foot," warns Hargrave, who said that most developers "shouldn't be writing these things."
A possible easier alternative or adjunct to OSGi modularization takes the form of Java Jigsaw (JSR -294) specs. Jigsaw spec work has been slow, according to viewers, as was the case with some other Java Community Process efforts during Sun Microsystems' final days.
The Jigsaw effort was not included in the soon-to-be-released OpenJDK 7, but has recently been mentioned as under review for OpenJDK 8 inclusion. Difficult as it may be, OSGi is here today, which gives it a certain edge against a Jigsaw-enabled OpenJDK 8 that is still in the future.
''I've always been convinced that the last thing Java needs is yet another module system. Multiple implementations are good but multiple specifications for exactly the same purpose are just not good," said Peter Kriens in an e-mail interview.
"Module systems are surprisingly hard to design and with OSGi we've got a proven mature solution,'' said Kriens, founder of consultancy aQute and an OSGi Alliance member. ''Though some see OSGi as too complex, the complexity is almost invariably caused by the boundaries that module systems erect."
"Jigsaw will run in these same walls or it will not be able to provide the benefits of modularity," said Kriens, who emphasized that these were his personal opinions and not the opinion of the OSGi Alliance.
Whether discussing OSGi or Jigsaw, it remains the case that building new modular applications requires refactoring existing code, which is always a potential pitfall.
''If you haven't refactored your bundles you are probably doing something wrong," Jeff McAffer, founder and CTO of EclipseSource, a software products, services and training provider, told an EclipseCon 2011 audience.
"Modularity is very good, but not if you do it the wrong way," McAffer said.