What to Depend On

Why do we need modularity in the first place? Lets get rid of this extraneous layer and make life simpler as Erlang's Joe Armstrong argues. Then again, maybe not.

The reason we need modules is that Object Oriented (OO) technology is starting to fail us. OO gave us a tremendous boost in productivity for 25 years but it is running out of steam for today's systems and especially for statically typed languages like Java. The reason is simply too much coupling. Using a single class from a library drags in its whole transitive dependency, to run even a simple program we have to download the internet. The independent evolution of these dependencies tend to create nightmares like JAR hell. After assemblers, subroutines/functions, modules, classes, and packages it is time for the next paradigm in software! A paradigm that must explicitly address the problem of too much coupling in Java systems.

Jigsaw and JBoss A7 claim to provide the solution to the dependency pains of Java by providing modularity since modularity provides encapsulation; we all know that encapsulation can reduce coupling. But do they? Sure, they make it much simpler to assemble a large class path because it becomes largely self assembling. However, they do not fundamentally change the way the class path works today. That is, they actually only provide a more convenient way towards JAR hell (Personally, I prefer a slightly different destination).

Worse, the hallmark of modularity, encapsulation, is severely compromised by the Jigsaw/JBoss model and Java's best practices.Virtually all Java code has become contaminated with class loading hacks to fight coupling. Java interfaces provided us with a tool to make clean decoupled class diagrams but at the same time created the problem of instance coupling: how to get the instance that implements that interface. In Java, instance coupling is generally achieved with dynamic class loading hacks. Unfortunately, most of those patterns need to violate the module's boundaries to get access to the client and implementation classes.

Once you see this problem (and it is not obvious), the solution is rather clear: we need a concept to handle the interaction between modules, a contract. Just like a class can implement one or more interfaces (the type contract), a module should be able to provide one or more services (the module contract). A module should depend on the services it needs, not on the JAR that holds those implementations. Exactly like a type should depend on an interface and not on an implementation class.

How to specify the service contract? An interface? The granularity of an interface is too small in almost all of the most trivial cases. In general a contract describes a collaboration between multiple actors, defined in interfaces, abstract or base classes, permissions, utility functions, etc.  Like Jigsaw, could we (ab)use the virtual module as the "interface" of a module? Nope. That model has no representation in the type system and is therefore fundamentally unsafe. It also is wrong to restrict a module to providing a single service; remember why interfaces were added to Java? Only because we had single inheritance and it was felt that the 1:1 relation was too constraining.

The logical choice in Java is obviously the package. A Java package is already the Java module: it provides encapsulation, a namespace, is part of the Java language, is part of the type system, it has a name, can easily be versioned, and it has the proper granularity for a contract. A module should provide a number of packages and depend on a number of packages that specify contracts between the modules. Just like methods provide the contract between classes. Since the dependencies are expressed in packages, modules can be substituted.

Anybody that doubts package imports/exports are a bad idea should consider that OSGi also supports the module-to-module dependency of Jigsaw/Maven/JBoss, it can even separate types. Since each OSGi user has the choice, why do you think that over time they use packages? Maybe because it works?

The need for package imports/exports is crystal clear when you really understand the violation of encapsulation caused by the interaction of the Jigsaw/JBoss programming model and popular Java patterns. Five years from now I might be able to say: "I told you so," but I still have hope that enough people will put in an effort to understand the looming problem to prevent another 5 years lost to the gains of true Java modularity.

Peter Kriens

Another bndtools Hackathon

The house feels rather silent after 4 days of intense hacking on bndtools with PK Sörelde, Neil Bartlett, Joakim, Stuart McCulloch, David Savage (remote from the UK), and Ferry Huberts here in my house. We closed a lot of bugs and we (well almost) reached our goal to run bndtools on the OSGi build faster than anything else. Then again, maybe I should say we reached our goal since Neil just informed me with Skype from an English bus that he was now really close.

Neil Bartlett started already quite some time ago to create the ultimate OSGi IDE based on Eclipse. Since he was using bnd to do the low level building I convinced him to also use the more advanced build features in bnd, which resulted in a fruitful collaboration. This brought ComActivity into the game. A couple of years ago they hired me as a consultant to help them with their OSGi work. At that time we used bnd as an Eclipse plugin to do the build. Last year they switched to bndtools since it has a much more extensive GUI. PK Sörelde from ComActivity even contributed the version release management tool. With over an increasing number of listeners on the bndtools list we were getting in an area that bndtools needed to become rock solid stable so it could be used by more people. Two weeks ago PK proposed to do an intense round of finalizing open issues and I gladly offered my house.

We also had Stuart McCulloch from Sonatype here to help us out with maven. Since maven is quite popular as an OSGi build tool with the maven bundle plugin, which is based on bnd, collaborating is quite natural. Initially we wanted to do the complete build in bndtools but after brainstorming we found out that we could use the m2-eclipse plugin quite elegantly for building, leaving the bundle development (coding, manifest, debugging, etc) to bndtools. Using m2-eclipse will give us full fidelity with the offline and IDE build.

The coming week we will test the heck out of bnd and bndtools and hope to release a rock solid fast new version next week.

So lots of bugs closed, lots of fun (the weather was fantastic!), interesting discussions, good food, lots of plans, and a very nice result.

Peter Kriens

American Pie

"Steve Jobs died," someone yelled in the San Francisco Hilton lobby. First a wave of sadness descended upon me and then I got angry at myself for giving in to celebritis. Yes, he is a big part part of the tools I use daily to get my work done and he is part of the many Apple gadgets around the house as well as much of their content, as so many people today. And it is likely he will sorely be missed in the coming years for not providing his constant stream of innovations. Every death is sad because something is lost forever but the death of a well known figure should not feel like someone close to you died. So why was it so hard to shake of this sadness?

There is of course the identification: Steve Jobs was only 3 years older, he worked in the same industry, and in moments of grandeur I have envisioned myself as a Steve Jobs if only I had been born a bit earlier and in the US instead of Rotterdam. When someone that plays such a role for you his death confronts you with your own mortality. So was this sadness only caused by a rather solipsistic fear of death?

I guess there was his constant presence through my career. When I soldered my first computer, he made the Apple II. When I designed our newspaper page make-up terminal in the eighties we got inspired by Smalltalk and Steve Jobs was inspired by the Alto, both closely related results from Xerox' PARC Place. Also Postscript, another result of PARC Place, was a shared inspiration though admittedly Apple made it viable with their LaserWriter. Around 1985 I developed an object oriented language called CO2. I had been inspired by Brad Cox, the inventor of Objective-C. So when Steve Jobs came up with the NeXT, largely based on Objective-C, I had to get one. A mind blowing experience only numbed by the excruciatingly slow optical drive.

So maybe the reason for the sadness was not egocentric but more the loss of the rare someone that shared the same enthusiasm for the combination of computers and esthetics. Someone that struggled with the same problems (though he admittedly much more successful than I ever did) in the eighties. Maybe the sadness is caused by losing the subject of a my rather rare envy. Though I share his focus on tomorrow but I do lack his ruthlessness and risk taking nature that is required for great products. His gusto to break backward compatibility only so that tomorrow's product could become better than anything else. I unfortunately tend to cave in because the others really seem desperate to want to have that feature ...

Of course I can rationalize that the almost absolute powers granted to a Steve Jobs are an anomaly and that in general we have to balance the interest of different parties. The route I've taken in my life is to find a better way to develop software, software based on collaboration and open environments like the OSGi Alliance. In such an environment compromises are inevitable but maybe the sadness is caused because Steve Jobs' death shines such a harsh light on all the compromises I agreed to only for backward compatibility and special interests.

And maybe one should not analyze those feelings to deeply and just accept the sadness, it will pass. And maybe after all it is just celebritis; for someone with very few heroes I guess am just not used to it.

Peter Kriens