[More of my first No Fluff, Just Stuff experience]
My last session on the first day of the "No Fluff, Just Stuff" symposium was another talk by Venkat Subramaniam called OSGi: A Well Kept Secret. It's interesting that Venkat titled this talk "A Well Kept Secret" because even after hearing it I must confess that the secret is still safe. I am not sure what to make of OSGi. Here is the OSGi website. Go there, and when you come back please tell me what it means.
The key catchphrase that I got from the session was that "OSGi helps you cope with classpath hell." Okay. Maybe I haven't worked on big enough applications, but I don't ever recall having serious enough problems with classpaths to call it hell. Apparently OSGi helps you manage multiple versions of a class. Hmmm. Why do I want to deploy multiple versions of a single class? I know there are times when you need multiple versions of software running, but this solution seems odd to me because you have to manage another run-time environment, and that just seems like more complexity than is warranted.
I think part of the problem was that the session was mostly spent configuring the OSGi environment and deploying various versions of "bundles," and no time was spent on running a real application against those different bundles. And how would it work with a WebSphere environment? The simple application that Venkat ran actually failed to show the gist of bundle management. The session ended before he got to fix whatever bug it was that caused the problem.
I guess I could see some value in OSGi, but it just seemed to me that it was a solution looking for a problem. Or even a solution whose problem no longer exists.
Next up: Drooling
2 comments:
It's a shame that the speaker you heard didn't really get across the essence of what OSGi is: it's a module system for Java.
The "hell" of Jars is that they are not proper modules. They are not versioned and you have no idea what dependencies they have. Have you never found yourself in a situation where a Java library throws ClassNotFoundException, and you don't know where to find the missing class? With a proper module system, it's easy to fix this kind of problem, because the module system tells you which module is missing.
I agree that the OSGi website is awful. But I do encourage you to take another look at OSGi, it's rapidly becoming the standard way to develop Java applications.
Thanks for you comment. Yes, I can see from your example where a module system would be beneficial, but I still don't see the OSGi solution as being worth it. I will have to take your advice and look a little deeper.
Post a Comment