My thoughts about OSGi on JavaWorld

A few weeks ago, I’ve been interviewed by Andrew Glover for JavaWorld’s Java Technology Insider podcast and it’s been published today. So without further ado, feel free to check out our talk here.

Now if you want to read it rather than listen to it, I’ve prepared a transcript for you guys. I’ve added a few links inside the transcript for the references I mention.

Like many Java developers, Sebastien Arbogast recently realized the potential of OSGi for server-side Java development. Since then he has founded the Javalobby’s OSGi zone as an information hub for announcements and discussions related to OSGi. In this talk with Andrew Glover, Sebastien cuts to the chase of why OSGi is such good news for Java developers on the server side. He also gives us an overview of the various initiatives, from app servers to Android, that are leveraging OSGi dynamic component model.

Andrew: Ok, so we’re talking with Sebastien in Belgium and Sebastien is kind of a thought leader behind OSGi on DZone so Sebastien, why don’t you tell us about yourself and then jump right in and tell us what OSGi is and why we should care.

Sebastien: Ok so, I’m an IT consultant right now in Brussels, Belgium. I’m working at a company called Axen. And we’re doing a lot of Java stuff. And as far as I’m concerned, I’m a Java architect. That’s one of the reasons why I care about OSGi. I’ve been caring about it only recently, but I find it very interesting. Actually, I’ve been developing in Java for something like eight years and the first four or five years, I’ve been using mainly J2SE, so mainly Swing stuff. And I’ve been working with J2EE for three or four years I think. And the very first system I built was a platform to ease the development and deployment of mobile data services. And in this first system, I already sensed the limitations of JavaEE platform, mainly because it was not modular, and that was a big problem, a big issue in this project because I wanted to build a system that you could easily add new services, new plugins, new modules to it, and with standard J2EE, either EJB’s or Spring for that matter, it was not really possible. At that time I was already looking at other frameworks but when I heard about OSGi then, I didn’t have a precise idea of what it was. The only aspect of it I knew was the fact that Eclipse was based on it and I thought “OK, OSGi, Eclipse, it’s about the same thing” and since I’m not really a big Eclipse fan, I didn’t really care about OSGi. And it’s only recently, at Javapolis’07, in last December, I attended a conference by Peter Kriens from OSGi, and he talked a little bit more about OSGi on the server side and all the implications it can have there. And that’s when I really realized that in fact, Eclipse is based on OSGi but there’s no close relationship between the two. That’s when I realized really the power of OSGi for server-side applications.

A: Ok. And so you eluded to the fact that Java itself is not very modular, and that OSGi can help solve that problem. What is it about Java that makes it unmodular?

S: Well, what is really critical is the way the specification is done, with EJB’s and web applications. Mostly you use WAR or EAR archives to deploy your applications. And unless you start using very application-server-specific formats like SAR or whatever, unless you use those technology-dependent formats, then you’re stuck with big monolythic applications. It’s really a all-or-nothing approach. And basically when you have to change something in one of your modules, and your modules are just traditional JAR libraries, then you have to package the up again in a WAR or EAR, and deploy it again, so the application is restarted, and in some mission-critical applications, it can really be a problem. That’s really what makes Java not really modular, and I think the best demonstration for that is to see the number of platform-like applications in Java. You have plenty of CMS’s, project management systems and that kind of applications in PHP or other interpreted languages like Python and so on. But you have very few such systems in Java, and I think it’s more precisely because it’s more difficult to build an extensive, dynamic and modular application in Java.

A: Ok. And so how does OSGi fix it? What are there fundamental changes, I guess, to the Java platform and how does this all sort of coincide with the whole Java modules JSR stack?

S: Well, one of the main flaws and one of the reasons why Java is not modular behind the scenes is really the classloading mechanism. In traditional Java, and especially in server-side Java, everything is about one big classpath bag and it’s very difficult to have several versions of the same libraries running side by side. I’ve had this situation plenty of times where you upgrade your application server, and it has some JSF or WebService support built-in, and suddenly your application, which has also embedded libraries for those usages doesn’t work anymore, just because there is a conflict. And the main thing that OSGi really brings to the table is a new, standardized and dynamic classloading mechanism. And that’s really what changes everything because suddenly you can use different versions of the same library side by side, you can dynamically load libraries, unload them, install them, resolve dependencies without even restarting your application, and not even the server itself.

A: I see. An so you eluded to the Eclipse platform that is OSGi-based so I assume this sustains the plugin architecture and your ability to load and unload plugins as you need to.

S: Yeah, that’s what they use it for. It’s really powerful. The way Eclipse is architected is really suited for this. I mean, OSGi is really suited for that kind of architecture. The only thing is that, on the client side, I don’t really see the point of using this technology. I mean, I had to do the design for an application recently and we had basically three options: using Netbeans RCP framework, Eclipse RCP which is based on OSGi, and custom Swing code. And we ended up with custom Swing code because developing on top of Eclipse RCP was too complex regarding the complexity of the application itself. I think, on the desktop it’s not that critical. But what makes OSGi really powerful is when you start to realize all its power on the server, because that’s where you need to make your application evolve without having to restart the whole thing. And I think that with all the buzzwords around Service-Oriented Architecture lately, it’s really awesome what you can do. You can really have your application living and remove old versions of webservices and add new ones, and that kind of stuff. So it’s really where it’s interesting.

A: Right, ok. So, can you tell us about the JSR 277 stack, and I guess there is also an OSGi stack (JSR 291), and what’s the deal? Why are there two stacks that seemingly address the same thing?

S: Well, that’s a good question, I mean, it’s really… interesting, I would say, to see how Sun reacts to OSGi because OSGi is actually standardized already in JSR 291, and it’s a final release, it’s completely ready to go. And yet it seems like they don’t want to use that implementation for modularization in JavaEE 6, because they have this other JSR that you mentioned, JSR 277, which is Java Module System. And I really don’t see the point, I don’t understand why they made that choice. It’s older than JSR 291 but it’s still in early draft, and apparently, it looks like it’s going to run only on Java 7, so I don’t really see how they can integrate it in JavaEE 6, which should be released some time this year or beginning of next year. So I don’t know, it’s really strange. And the strangest thing is that the expert group for the JSR 277 said that they would support, that there would be a bridge, a compatibility effort to support OSGi, so JSR 291. So I don’t really see the point in Sun’s strategy, not to integrated OSGi right now because it’s been in use for a few years, it’s already gone mature after four major releases, we’re on the fourth release now and they’re preparing for the R5. So I don’t see why, it’s really a mess with all those JSRs, and even more so as there are other JSRs which cover some small aspects that OSGi covers as well, like the JSR 294, superpackages, and it addresses some issues that OSGi already covers.

A: So I guess this would not be the first time a JSR and the JCP process is causing some angst in the community. Who else uses OSGi?

S: Well, right now it’s very interesting to see that there are a lot of efforts going on to exploit the power of OSGi on the server side. Of course there are already some implementations. Because OSGi is basically just a specification, exactly like the kind of specification that the JCP tends to produce, so it needs implementations. And so there are already the Knopflerfish implementation, which is quite old. Now we have also of course the Equinox one, which is the one from the Eclipse foundation, the one that they use at the heart of Eclipse, and that can also be used on the server side. And of course there is the Apache Felix project, which also implements OSGi R4.

A: Tell me more about Felix, the Apache Felix project. What is it? I mean, obviously it’s an OSGi implementation, but how do you use it?

S: Actually to use OSGi, the first thing you need is really an implementation for the platform. It’s just the kernel, the core bundle – because OSGi is all about bundles, you compose your application in modules that you can plug together and start up, stop, and so on. And there is one core module, core bundle that actually starts up the whole thing and is able then to load other modules, to start them up, to shut them down, and so on. And what Felix does, it implements these basic bundles, plus a few others that offer administrative services and so on. But the main part of an OSGi implementation in general, and Apache Felix in particular, is really to implement the kernel specification.

A: Right, ok. So then from an application server standpoint, who’s looking at OSGi? Who’s implementing it? Who’s ahead of the pack?

S: Well there are a few efforts there as well. Maybe the older one I know of is JonAS, which is an Open Source Java application server, and JonAS 5 is completely based on OSGi, which means that even the EJB support is made up of OSGi bundles, and on JonAS 5, you will be able to deploy your applications with just small bundles. And I think that right now it’s really the most advanced implementation, at least in the Open Source world. Then there is also BEA, who’s working on something that’s really big and strategic for them. It’s called micro-service architecture (MSA). So basically the next version of BEA application server is going to be based solely on OSGi bundles. They are going to sell individual bundles, so that you can really compose your application server depending on your very specific needs. And I thing that JBoss is working on something as well, it’s more something internal to the server. Until now, they were using JMX for their micro-kernel, and now they are porting it totally to OSGi. But it’s really internal, normally it should be transparent to developers, and we shouldn’t see any change on the JBoss side. IBM is working on it too, because I think Websphere 6.1 is using OSGi at its heart. Of course because IBM is behind Eclipse and they’re supporting OSGi very heavily so they implemented OSGi in Websphere as well. And that’s it for the application server efforts that have been announced, but if I can just try a little guess, I would say that SpringSource and Covalent, which they have acquired recently, might be preparing something but it’s really just a guess.

A: Ok. There surely has been some speculation on stuff about how Spring may adopt OSGi. What does that mean in terms of Spring and OSGi?

S: Well, right now they have already gone through a very important initiative since the enterprise expert group – which is the entity inside OSGi who’s thinking about the server-side specification for OSGi. And SpringSource has been working with them very closely and they already released the final version of Spring Dynamic Modules, which was formerly called Spring OSGi. It’s really interesting because it comes on top of the application server as a way to ease the development of bundles and the connection of bundles with one another, and especially a feature that implementations like Eclipse don’t use very much, which is the service dependency mechanism. And Spring Dynamic Modules is really a great way to simplify that.

A: Ok, now there’s also been some talks about Android on the Open Handset stuff from Google and the rest of the big wigs there, that also is OSGi. So, if OSGi makes a lot of sense for the server side, how does it fit in Android? What does that mean?

S: Well, I’ve only read a few things about OSGi history, but I think that OSGi originated on embedded devices. When it was designed, the first release was really for embedded devices because, when you do some Java ME stuff, and I’m doing JavaME development myself, in order to handle the fact that all mobile devices are so different in their capabilities and the kind of features that they can support, the mechanism that Sun proposed for JavaME is the profile thing. So you have MIDP which is the most popular one. And basically, a profile is just a set of APIs, a set of libraries that are to be implemented on a mobile device so that you can use those services in your own applications. The problem with that is that it introduced a whole lot of fragmentation on the market because those libraries are just specifications. Sun provides some reference implementations but then the mobile device manufacturers have the responsibility to actually implement those specifications and you can have very different variants of the same profile on different phones and it’s really a pain. So I think that OSGi answered this need as well because it removes the need for profiles. Instead of having to bundle libraries in profiles that try to support categories of phones, you can really have modular support on mobile phones, and for example, if there is one phone that has a GPS receiver in it, then there can be the GPS supporting bundle, otherwise you remove it. OSGi really originated on embedded devices, and now it’s like the cycle is closed with an open platform like Android, and I think that other platforms will have a look at it as well.

A: Excellent. So, how can people find out more about OSGi?

S: Well, there are several ways. Basically, the OSGi official website has a lot of very interesting documentation. Of course there is an article series on Javaworld as well, and I read the first episode, it’s really interesting. I think BEA has also a very interesting article series about it. IBM developerWorks network also has some documentation. Right now, it’s a little bit fragmented, and many people are trying to write some tutorials here and there, and it still misses the pragmatic side of things. Actually, how do we develop for example a web application using OSGi? And I think it’s going to come in the months to come, as OSGi is really about to finish their R5 specification, and we should have some very important information then. And what we are trying to do at DZone, because as you said at the beginning I’m a zone leader for the OSGi zone, and we’re really trying to centralize all the information, all the news about OSGi, documentation and so on. So I would say come and have a look at and you can have a few articles with a few references to the most popular tutorials about OSGi.

A: Excellent. Well thank you very much for taking this time out to call us from Belgium. It’s been very interesting to learn about OSGi and so, as you said, if you really want to get all the information about OSGi, check out, and Sebastien you’re the Zone leader for that group, correct?

S: Yeah, exactly.

A: Excellent, well thank you very much for your time and we will look forward to learning more about OSGi.


8 responses to “My thoughts about OSGi on JavaWorld”

  1. o/

    I read your interview and say “sh**, I’ve been working for two years on something else to read today there is something better on Earth, which solves some problems that we have right now.”

    After reading it, I will start reading more about OSGi, and will look for another app server

    So, can I add a question to this interview? How about flex? How OSGi on server side can helps flex Appliactions?


  2. Great spirits think alike, Velo. I’m currently playing with Solstice ( and even though it’s still a very early draft, I’m gathering bits and pieces to integrate it with Spring Dynamic Modules and Maven. And hopefully I’ll have a tutorial ready soon… Now could someone add a few hours to each day?

  3. There is something I don’t understand, and perhaps you can enlighten me. JSR 277 is supposed to replace (among other things) the jar system. I.e. it is supposed to address the modular composition of “static” applications, meaning applications that DON’T change their modules at runtime. Most Java applications are static. True, it also addresses dynamic applications as OSGi does, but this is not necessarily JSR 277’s main target problem. Now why is it that the OSGi people got all over this JSR? I want to write simple, static applications without jar/classpath hell, and JSR 277 mainly addresses THAT issue. Now, why won’t the OSGi people leave the spec team alone to do their work?

  4. I don’t see the point in replacing the JAR system if it’s not to add dynamic features to it. And judging by the adoption of OSGI, this is really a major requirement from the community. Why won’t the OSGi people leave the spec team alone? I’m not part of OSGi myself, and the JCP is supposed to be the mechanism by which Sun listens to the community to enhance the Java platform, not a set of deaf comittees who do their thing on their own.
    Now OSGi (JSR 291) already deals with the issues you mention, plus it adds dynamism with no major cost, so why reinvent the wheel?

  5. The point is to be able to specify module dependencies and compatibility information. This is important even for applications that don’t change modules at runtime – it allows easier upgrades and module sharing. Now JSR 277 gives you this without writing your code in the form of dynamically loadable modules. It simply replaces the system class loader with a more sophisticated one, and replaces the jar with a module archive that allows more flexibility, control and tidiness. From what I understand, to write an OSGi application, I need to write my code as OSGi modules, and provide load and unload hooks, similarly to Netbeans modules.

  6. You’re not forced to write load and unload hooks. The only thing you need to do to bundle-ify a JAR is to add more information to META-INF/MANIFEST.MF. Now is this small overhead worth the development of a whole new standard that does much less than an existing and mature one and even competes with it? I don’t think so.

Leave a Reply