At its core, OSGi is very simple and, as with all good and simple ideas, many people have independently invented their own versions at different times and places. None of these have achieved the maturity or widespread usage that
4Also note that Concierge has not been certified compliant with OSGi R3, since OSGi
Alliance rules only allow implementations of thecurrent specification release to be cer- tified.
OSGi now enjoys, but it is informative to review some of these alternatives. At the very least we may learn something about why OSGi has made the design choices it has made, but we may also find good ideas that can be brought into OSGi.
1.8.1. Build Tools: Maven and Ivy
Maven and Ivy are both popular tools that have some characteristics of a module system, but they are build-time tools rather than runtime frameworks. Thus they do not compete directly with OSGi, in fact they are complementary and many developers are using Maven or Ivy to build OSGi-based systems. Maven is a complete, standalone build tool, whereas Ivy is a component that can be integrated into an ANT-based build. Both tools attempt to make JARs more manageable by adding modular features to them. Principally this means dependencies: both allow us to specify the versioned dependencies of a JAR using metadata in XML files. They use this information to download the correct set of JARs and construct a compile-time classpath.
However, as they do not have any runtime features neither Maven nor Ivy can solve the runtime problems with JARs, such as the flat global classpath, the lack of information hiding, and so on. Also the metadata formats used by these tools is unfortunately not compatible with the format used by OSGi, so if we use Maven or Ivy to build an OSGi-based system we typically have to specify the metadata twice: once for OSGi and once for the build tool. However, some efforts are currently being made to better integrate Maven with OSGi.
1.8.2. Eclipse Plug-in System
As already noted, the Eclipse IDE and platform are based on an implemen- tation of OSGi. However this was not always the case: prior to version 3.0, Eclipse used its own custom module system.
In Eclipse terminology, a module is a “plug-in”. In fact, Eclipse developers often still use the term plug-in as an alternative name for an OSGi bundle. In the old Eclipse system, a plug-in was a directory containing a file at the top level namedplugin.xml. This file contained metadata that was broadly similar to the metadata in an OSGi manifest: the name of the plug-in, vendor, version, exported packages and required plug-ins.
Notice a key difference here. In the Eclipse plug-in system, dependencies were not declared at the level of Java packages but of whole plug-ins. We would declare a dependency on a plug-in based on its ID, and this would give us access toall of the exported packages in that plug-in. OSGi actually supports
1.8 Alternatives to OSGi 23
whole-bundle dependencies also, but the use of this capability is frowned upon for reasons we will examine in Chapter3.
The biggest deficiency of the Eclipse plug-in system was its inability to install, update or uninstall plug-ins dynamically: whenever the plug-in graph changed, a full restart was required. In early 2004 the core Eclipse developers began a project, code-named Equinox, to support dynamic plug-ins. They intended to do this either by enhancing the existing system or selecting an existing module system and adapting it to Eclipse. In the end, OSGi was selected and Equinox became a leading implementation of it.
1.8.3. JSR 277
Java Specification Request (JSR) number 277 is titledJava Module System[9] and as such one would expect it to attempt to solve a similar set of problems to OSGi. However JSR 277 tackles them in a different way to OSGi.
The most important point to note is that, at the time of writing, JSR 277 is an incomplete specification with no implementation yet. It is scheduled to be included with Java 7 but it is unclear when (or even if!) Java 7 will be released. An Early Draft Review (EDR) of JSR 277 was released in October 2006, which is the best information currently available.
Like the old Eclipse plug-in system, JSR 277 does not support package-level dependencies, instead using whole-module dependencies. However JSR 277 differs further by using programmatic resolution “scripts” rather than declar- ative statements to resolve module dependencies. This allows for extreme flexibility, but it’s debatable whether such flexibility is ever necessary or desir- able. Programmatic code can return different results at different times, so for example we could write a module that resolves successfully only on Tuesday afternoons! Therefore we completely lose the ability to use static dependency analysis tools.
Furthermore, JSR 277 is not dynamic, it requires the Java Virtual Machine to be restarted in order to install, update or uninstall a module.
In a sense, JSR 277 is an affirmation from its sponsors (principally Sun) that modularity is important and currently missing from standard Java. Sadly, JSR 277 comes many years later than OSGi, includes some questionable design features, and is substantially less ambitious despite its opportunity to change the underlying Java runtime. Therefore we hope that JSR 277 will at the very least be compatible with OSGi, since it currently appears to represent a significant step backwards for modularity in Java.