Update: A great article on OSGi popped up on Javalobby today. Check it out.
I haven't yet written any thoughts about OSGi but it's something that's increasingly found its way on to my radar over the past year and a half or so. I've been doing a little bit of reading and research on it lately, (a quick introduction can be found via Adrian Colyer's talks on InfoQ about it). Needless to say it's got me excited. Really excited – to the point where I'm catching myself geeking out uncontrollably like Quagmire from Family Guy. What's got me all giggity? Let's take a step back first.
With Java there has always been a focus on modularity, but it's come up in different intermediate forms. Any typical Java developer can go on for hours about the importance for layering and properly isolating, decoupling and packaging components and subsystems. Java has the idea of a package, and the idea of JARs came about fairly early on in the process. But what became difficult was that often each layer had to have its own supporting infrastructure in place to be built independently, and someone needed to know how all of those JAR dependencies mapped out at build time and runtime. This was a necessary evil so that we could have individually deployable modules or subsystems. Once you got there, it was all worth it.
The problem was that while you may have been diligent and rigorous in your approach to applying how your projects were laid out and built, quite often the framework space solved this problem over and over again in many different ways. Going to upgrade a library was not an easy task, because you had to typically upgrade it across each of your layers, and what's more, there was no consistent approach to manage transitive dependencies amongst the modules each library used. Library selection and dependency management was the work of a greybeard within your project and it took a while to change a library or upgrade. Not to mention a near certainty that you'd need to execute your entire suite of regression tests to make sure nothing broke.
After seeing many Java frameworks being cajoled into a Maven build in order to manage builds and transitive dependencies, there has been increased awareness on the part of the vendor (be it commercial or open source) space on modularity. But we've only focused on the problem of solving modularity from a build-centric view. In other words, "How can I package and manage these build artifacts in such a way that consumers can easily integrate them into their project in a consistent and automated way?" This was the pie-in-the-sky idea behind Maven as I see it, and they pretty much made it happen. You'd be hard pressed to find a framework today that doesn't support it in some fashion.
If you're the type that keeps up with the JCP space, you probably know there is a JSR "trinity" (equally as mysterious as its holy counterpart to the outside viewer) to provide a more robust modularization mechanism in varying degrees. That "quagmire" withstanding, OSGi has been mounting a considerable lead as the modularization system of choice in the JavaSE and EE/App server space. (It was already a formidable player in the embedded/mobile space, where it evolved from.) Nearly all major App server vendors have integrated the OSGi model into their core, which means they've probably cleaned up any classloader nastiness they've resorted to in the past. And now you're seeing some of the leading frameworks like Spring and Web Beans/Seam 3 (and subsequently have signed up to publish themselves as OSGi bundles.) Not to mention the success that Eclipse has seen since refactoring itself to work off its OSGi implementation, Equinox.
If OSGi can continue to make inroads in the framework space, I think its prospects to the "in the trenches" Java developer are very exciting indeed. Expect me to babble on more about this in the future…
More Related Content
- July 24, 2009 — The Elements of Reusable Code (0)
- June 3, 2009 — What is Hamcrest? (0)
- November 28, 2008 — Must Haves/References For Modern Java EE Developers (1)
- November 19, 2008 — Java 6 and Maven 2.0.9 on Leopard (7)
- March 19, 2008 — New Wave Logging (0)
- January 7, 2010 — Eliminate Branching (IF Statements) to Produce Better Code (0)
- July 29, 2009 — What I'd Tell Myself About Design If I Were Just Beginning (5)
- June 9, 2009 — Mocking with JMockit (3)
- January 31, 2009 — In response to Stackoverflow #38/"Quality Doesn't Matter That Much" — Jeff and Joel (3)
- January 21, 2009 — 16 Apps That Lessen TEH SUCK of Web Development in XP (8)