Modular Mind

One of the talks I give most often is called “Why Java Modularity Matters”. This is my attempt to explain how modularity in general and OSGi in particular represent the next logical step in the evolution of software development. I’m actually giving this talk at the Madison Java Users Group tomorrow night, and if you’re in the area please feel free to stop by.

Anyway, I spent some time last week moving the presentation over to Prezi, which I’ve been interested in trying for a while. What I like about Prezi is that it allows you to convey structure and meaning in ways that are impossible with regular slideware.

If you’re interested in what this looks like, check out the presentation embedded below. It’s obviously not meant to convey a lot of information on it’s own, but you’ll get the general idea. And as always, I’d be interested to hear what you think.

What does the term application mean in the context of modular software development (and OSGi in particular). It seems to me that the concept of an application starts to break down. For instance, is an OSGi application just the set of bundles known to the framework?

Well, here’s my take on what a modular application might mean.

Going beyond the steady state

When an OSGi framework fires up, some bundles may be activated, others may not. Some activators may perform logic, others may not. But what arises from this activity? Is this the equivalent of launching an application? It can be, but its more often the case that the framework arrives at a steady state, waiting for an input that triggers some behavior.

This can be confusing when we start using OSGi because this doesn’t look like an application. What we need is an entry point. Just as throwing a rock into a pond causes waves to form, we need to launch a thread of execution that takes us beyond the steady state. So how do we accomplish this?

Eclipse applications

The Eclipse platform provides us with one answer in the form of an Eclipse application. An Eclipse application is defined through the org.eclipse.core.runtime.applications extension point and is represented by an IApplication instance at runtime. And this mechanism can easily be added to Equinox by installing some additional bundles.

This is how, for example, Eclipse RCP applications are launched in the context of an OSGi framework. But it’s interesting to note that one set of bundles may support multiple applications. So a good way to look at an application is that it is merely a specific entry point into the functionality provided by a community of bundles.

The OSGi Application Admin service

We can take the concept of an OSGi application one step further by utilizing the OSGi Application Admin service. This service recognizes the concept of an application in the abstract (specific providers can define what an application means in each case), and allows an application to provide an entry point that will launch a thread of execution.

Equinox, for instance, provides an application descriptor for Eclipse applications. This means that you can use the Application Admin service to start and stop Eclipse applications from the OSGi console. The available console commands are:

• apps – list currently available applications
• activeApps – list currently active applications
• startApp [app id] – start an application
• stopApp [app id] – stop an application

These commands can be used to launch most types of Eclipse applications, including those with an SWT user interface. Unfortunately, they cannot yet be used to launch Eclipse RCP applications because of the way in which singletons are used. This is scheduled to be fixed as part of the e4 work.

Possibilities

I think all of this is pretty exciting because it allows us to reimagine the relationship between applications, modules and running platforms (JVMs and OSGi frameworks). For example, imagine being able to deploy an Eclipse RCP application into a running OSGi-based ESB. The application would allow you to manipulate the ESB in container and it could then be undeployed when no longer needed. All of this could be done without restarting the ESB.

It’s going to be fascinating to see how of all this plays out in the next few years. The possibilities are endless!

While there are a ton of benefits to be gained from adopting OSGi, it’s not a trivial task to migrate your existing code. Class loader issues can bite you and perhaps the biggest pain-point is the migration of third-party libraries.

Third-party libraries are a problem because while bundle repositories are growing in size, there are still a lot of JARs out there not packaged as OSGi bundles.

So what can we do to make it easier to adopt OSGi?

The Knoplerfish answer

Well it turns out that the Knoplerfish OSGi framework has solutions to many of these issues. Among the features offered are:

• Automatic runtime generation of manifests for non-bundle JARs
• Automatic patching of code that uses inappropriate (for OSGi anyway) class loading mechanisms
• Ability to execute static main methods inside of the framework

These solutions are covered in detail in this presentation given last year.

Why are these solutions not more popular?

I’m wondering why these types of solutions are not discussed and suggested more. Are there similar features in Equinox and Felix that I’m not aware of? And if not, are there any plans to implement them?

I’d love to hear from others whether features like these would be useful to you or not. I’d also be interested to hear what else could be done to make OSGi adoption easier. In my opinion, the difficulty of migrating applications to OSGi is one of the main things holding it back. What can we do to fix this?

I’ve seen a number of blog posts and tweets lately asking some version of the question Why is OSGi important? If you’re one of the many people looking around at the increasing usage of OSGi and wondering whether it matters to you, here’s my answer.

I’m going to start by making a pretty audacious claim, which is that OSGi is one of the most important technologies to have arisen in the last 20 years. This does not mean, however, that OSGi is a revolutionary technology. In fact, OSGi is so important because it represents the logical next step in the long-term evolution of software development.

Where we’re coming from

To understand what I mean, let’s go back 20 to 30 years to the time when object oriented languages first became popular. One of the main reasons we adopted OO at that time was because it allowed us to hide many of the implementation details of our code.

Moving from procedural languages to OO languages allowed us to develop classes exposing a contract defined by a set of public methods.

The result was that much of our code was invisible outside of its class, and this had profound implications for the way we develop software. By accepting the apparent restriction of visibility we gained immense freedom. We gained the freedom to reuse classes without knowing their implementation details. We gained the freedom to refactor our code without worrying about the consumers of a class.

Can you imagine what a pain it would be if you had to develop software without information hiding?

Where we’re headed

Now imagine what it would be like if you could hide not only the methods within a class but entire sets of classes within a JAR. Imagine that JARs could define public contracts the same way classes do, and that these contracts would be enforced both during development and at runtime. Imagine that we could achieve all of the benefits of information hiding (managing complexity, code reuse, testability, refactoring, etc.) at an entirely new level.

OSGi makes this possible by offering up the standard Java package as a new unit of information hiding. When our code is running inside of an OSGi framework, each package in a JAR can be either exposed or hidden from consumers of that JAR.

Just as a class has a small set of public methods representing its contract with consumers, a modularized JAR (a bundle in OSGi terms) has a small set of exported packages representing its public contract. The bulk of our code lives in internal packages hidden from other JARs.

Imagine being able to rename classes, split or combine classes, move classes from one package to another, move entire packages from one JAR to another, all without having to worry about impacting the consumers of a JAR. So many of these types of refactorings are skipped now out of fear. Package level information hiding gives us the confidence we need to perform these refactorings, allowing us to react with agility to the changing needs of our users.

Modularity is inevitable

Whether OSGi in particular succeeds or not, JAR level information hiding is inevitable. The benefits are simply too great to ignore, and in 5 or 10 years we’ll all be wondering how we could have possibly lived without it.

Currently, OSGi is the only tool we have to accomplish this. Luckily for us it’s a well though-out, well tested, standards-based solution. I can’t think of one reason (besides perhaps its name) to develop an alternative to OSGi. It’s here. It works. Let’s use it.

It’s time for OSGi

Steve McConnell has a great quote that really gets at the heart of what OSGi is trying to achieve.

In Code Complete, he writes:

Software development has advanced in large part by increasing the granularity of the aggregations that we have to work with.

Because this granularity of aggregation is so critical, the move from unmodular to modular practices is as important as the move from procedural to object-oriented practices. For 20 years we’ve been limited to using the class as our unit of abstraction. As successful as that has been, it’s time to move on to modules. Its time for OSGi.