Ease of Use and Spring

Things should be as simple as possible, but not simpler.

As true as this is, the boundary between simple and simplistic is unfortunately highly subjective. If something works for you, don't change it. Unfortunately, many developers are in a situation where the environment and problems are highly complex and OSGi can simplify such situations.

The primary value that OSGi brings to the table is when you have to maintain a large code base over long periods of time, you have many external dependencies, you need to provide middleware, if you work with multiple developers, or if your development is spread over multiple locations. For those situations OSGi provides a type safe module extension to Java that can significantly reduce your development complexity.

So what is the usability issue? Unfortunately, both the modularity and type safety are at odds with prevailing class loading patterns in Java. OSGi is often the messenger telling you that your baby is neither modular nor really type safe. For example, Dependency Injection in Spring requires access to implementation classes from the configuration, exactly the classes you should really keep private. Worse, dynamic loading is only type safe if there is a single namespace in the universe. A single namespace causes DLL hell aka JAR hell that OSGi prevents by managing multiple class name spaces in a type safe way.

These are not OSGi problems, if Jigsaw one day will be modular and type safe it will have exactly the same issues!

To get the many benefits of modularity and type safety you must therefore change the way you think about Java ... If something is inside your module everything works as before but if you want to work with other modules you need to consider type safety and module boundaries. Object Oriented Design forced you to consider inheritance, encapsulation, and object identity, things that did not exist in Structured Design. Java modularity requires just such a paradigm shift. What we need is an inter module communication mechanism that truly hides implementation classes and enforces the type safety across modules. OSGi services are such a mechanism.

As Spring heavily relies on dynamic class loading it ran head on into the module boundaries and multiple name spaces. The resulting mess is what causes the negativity. Though Spring DM included OSGi services the problem was that they were more supported than embraced, resulting in many Spring DM/Blueprint modules to use the existing dynamic class loading model. However, this results in the import/export of large numbers of implementation classes. Exporting/Importing implementation classes increases the public space, the opposite of modularity. The history would be very different if the Spring libraries had embraced services, setting an example for true modularity.

There are only two solutions to this problem: Change OSGi or change the world. As I do believe there is no value in a little bit of modularity I can only see false advertising value in punching convenient holes in the modularity story of OSGi.  I do believe it is worth keep strong modularity and its enforcement. Very large applications like Eclipse, Websphere, JDeveloper, and others demonstrate that at certain scales OSGi becomes a necessity. And as more and more open source projects start to embrace OSGi it will become easier and easier to build OSGi based systems.

That said, as Rod justly points out, there are lots of people that are happy with Tomcat and depend on hard core dynamic class loaders. The OSGi service based programming model could provide benefits to these applications even if it did not enforce the boundaries. We're therefore thinking about a version of OSGi that inherits the class loading architecture of whatever environment it runs in; a JAR on the class path is then treated as a bundle. For example, in a WAR all entries in the WEB-INF/lib directory would be available as bundles. Karl Pauls tested this and it is a testament to modularity that many existing bundles actually worked out of the box. Though this solution obviously does not help when you are in JAR hell, it does provide many of the benefits of OSGi in your own familiar environment. And one day, when JAR hell finally arrives, the OSGi Service Platform is there to serve you.

Peter Kriens