In the Hopper: OSGi and It's JSR "Friends"

Since attending ApacheCon and sitting in Richard Hall’s session on, as I called it, “OSGi and Friends,” I’ve been interested and concerned about what’s up going on with OSGi and the “shadow JSRs” currently in the JCP.

What do these things do?

The goals of both of these clutches of efforts are to add more modularity and “component-ness” to Java which is much welcome from folks like me. As many people have said, “like assemblies in .Net.“

In helping to architect and develop a plugin architecture at BMC for their BMC Performance Manager, the team spent many an hour, days, and weeks trying to figure out how to make the runtime more modular. The Holy Grail was the ability to run multiple versions of the same classes (or plugins) at once: it was never solved while I was there.

I’m not sure why we didn’t consider OSGi: I’ve been following up with the folks recently and hopefully I’ll find out. That said, knowing more about OSGi now, it seems like it would have solved our problem and in a standard way instead of those damn, proprietary JBoss SARs.

Because there’s a lack of featureful packaging in Java, you always end up fighting the class loader when building large, plugin architected systems. Java security also laces it’s hydra-head in this area. In my long Java career, esp. when writing JAAS in Action and writing monitoring and management libraries to monitor WebLogic, WebSphere, JBoss, and the more elusive “standard” JMX servers, I’ve gone up against The Great Beast ClassLoader many times. Each time I got bitten and frustrated. (Thankfully, one the smarter coders re-wrote the JMX crap I was forced to produced.)

With all that tediousness over the years, something like OSGi seems wonderful. Of course, I haven’t actually coded with it, so I just know the claims. But many people seem to like it, and in edition to existing implementations, like Eclipse Equinox, there’s an Apache project (Felix) underway.

Logging: A Cautionary Tale

So, it was a bit troubling to find out that there are 3 JSRs in the JCP to implement a new version of OSGi. My immediate thought was “oh no, here we go with java.util.logging all over again. That forking of a de facto API went like this: for years, there was no logging facility in Java except System.out.println. Then, log4j came along, and many folks liked it and used it. Then, with Java SE 1.4 (man, what a great release that was, huh? It has regex too!), Java SE shipping with a whole new logging API, packaged up in java.util.logging.

Then you had at least two, actually more, logging API’s out there. To “solve” that we now have a logging API for logging APIs, commons logging. The end results are:

• More time wasted figuring out and arguing intra-team about which logging API to use.
• Third parties may use other logging APIs, leading to deployment annoyances.
• Worse, you often end up with a system that has at least 2, if not more, ways to configure logging, leading to wasted time in production.

In summary, too many choices in software development often lead to waste.

Compromise

Now, my “style” of architectural decisions is to choose the simplest solution, compromising beauty right and left. Thus, I’ve long held that you should use java.util.logging because it’s bundled with SE. log4j and other APIs may actually be better out-of-the-box, but it’s more JARs and non-SE code to get, understand, and maintain. In software, the ugly, but known code is preferable to the beautiful, but mysterious chunk on the horizon.

Avoiding API Proliferation

Though I’m a strong advocate of using the logging API in SE, the existence of java.util.logging instead of the integration of log4j into SE always seemed like a very high-level failing of the JCP: there’s something up with it that prevents it from making official standards out of de facto standards.

At first blush, you can dismiss it as NIH, not invented here syndrome. The positive side of that is the desire to have more control over the API.

To be honest, I don’t know enough of the inside history of logging to make the call: there could have been preventative crap on both sides. BUT, it strikes me that whatever the current state of things, we have a chance to avoid the same forking with whatever modularity system eventually gets into Java.

Request for Comment

So, as the title of this post implies, I’ve got this in the hopper. I’m interested in talking with people from all sides to figure out what’s going on here. So far, my conception is that there are two sides:

• OSGi – this stuff exists and works. Why come up with something new?
• JSR’s 277, 291, an 294 – these specs are in process and will work. Why stop their development and use something new?

There could be other camps out there as well. While I feel quite confident in nailing down the position of the OSGi camp, I’m not sure what the Sun/JSR position is. Both, however, are just what I currently perceive. As I often tell people, I hope to be proven wrong.

Luckily, I’ve been engaging more and more with the Java folks at Sun, RedMonk already talks regularly with the Eclipse folks, and I think I’ll be able to hunt down plenty of people in-between and further out.

I’d appreciate and insights, clarifications, links, and insights. Anyone got the goods?

Disclaimer: Sun and Eclipse are clients, as is BMC.

Tags: apachecon, eclipse, jcp, jsr277, jsr291, jsr294, osgi, plugin, standards, sunw