This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
| 1) Would there be case study on application adopting OSGi that made a difference?
Yes, in the book we follow through an 'auction application' case-study showing how moving to OSGi (a) makes the application more flexible and therefore easier to add features to it, (b) makes it more robust and thus avoids having us to change large parts of the application even though new features have been added.
In a nutshell though, the larger value is that OSGi makes it easier for you to create applications that act as frameworks in the sense that they are flexible and modular from the very beginning.
| (2) Any downside of OSGi? (e.g. performance overhead)?
I don't particularly address downsides, but rather point to pitfalls, one of which is the initial complexity of designing modular applications.
| 3) Other JVM languages are getting more popular, how do you see a mix of OSGi with others (e.g. Scala, Groovy)?
Due to the fact that the OSGi framework and its services are modular, factoring in other languages is not a problem. For example, OSGi is in the process of 'defining' a command-line shell for its own management which is based upon a dynamic language as opposed to plain Java.
| 4) Does Java version matter? (e.g. works better on Java 7)
Not particularly, the only caveat is regarding the usage of generics.
OSGi v4.2 does not rely on generics, however v4.3 does use it.
Any particular reason why you mentioned Java v4.3 here in your answer to Raymond? Also I did not understand how being a modular framework itself and borrowing from several dynamic programming platforms, OSGi makes modular design difficult. Colud you please elaborate/illustrate? (I am a designer/architect but new to OSGi).
Java Pal - Your friend in technology and innovation...India.
Alexandre Castro Alves
Joined: Aug 22, 2011
The point I wanted to make was that OSGi v4.3 uses generics in its interface (i.e. OSGi framework API), therefore if you are planning on using this version, it is advisable to use a Java version that likewise supports generics. If you are planning on using OSGi v4.2, then you can use an older version of the Java SDK without any loss.
Sorry for not being clear, but I meant OSGi v4.3 and not the Java SDK version.
| Also I did not understand how being a modular framework itself and borrowing from several dynamic programming platforms, OSGi makes modular design difficult.
Again, what I meant is that offhand spending time properly designing for modularity demands a higher upfront cost; this is true for any technology, and not specifically related to OSGi. In fact, I would say OSGi as a tool makes it easier to design for modularity as it makes you think about it and enforces it from the very beginning.