In an interview TheServerSide did with Rod Johnson, after discussing the core Spring framework and the evolution of the Spring TC Server, Rod was asked about his take on the topic of OSGi. TheServerSide transcribed his comments on the topic while also providing the audio of what was said, all under the headline of “OSGi: Not Easy to Use. Not as Productive as it Should Be, says Rod Johnson.”

Perhaps not surprisingly, the article garnered a great deal of attention, a barrage of comments from those in the OSGi community in defense of their technology, a few articles discussing OSGi's ease of use, and it even got Rod Johnson to log into TheServerSide for the first time in over two years to clarify his position, while providing a proper context for his comments.

In fairness to both Rod and the OSGi community, we’re republishing Rod Johnson’s comment on the original article, allowing the General Manager of the SpringSource Division of VMWare to more properly frame his stance on the discussion.

"I’d like to add some clarification here, and say a little more about our experience with OSGi and my conclusions from it—note the emphasis on my, as my opinions aren’t always those of SpringSource or VMware.

"We made a major investment in OSGi in creating our dm Server product. We subsequently took that technology to Eclipse, where it continues to move forward, with our continued input. We have an ongoing revenue stream from our OSGi-related technologies,with customers including some household name companies. We plan to maintain our current level of commitment to OSGi.

"The lessons I personally drew from the experience were that:

(a) OSGi is a great solution for complex applications with stringent modularity requirements;
(b) typical business applications (from which we make the bulk of our revenue) don’t have such requirements;
(c) our efforts to reduce the complexity of writing server-side OSGi applications were promising, but the road to simplification was longer and less certain than we’d hoped.Thus continuing down that road at the Eclipse Foundation, in partnership with other companies and individuals, was a natural move.

"I don’t think OSGi is a bad technology—merely one that isn’t applicable to every application out there and one which therefore didn't belong at the core of our business. If you don’t have modularity requirements, the simplest thing that can possibly work won't have a module system. I applaud the fact that the Virgo project continues to make progress in simplifying the OSGi experience, and am proud that our engineers play a major role."

Rod

So Rod confirms what he previous said about OSGi.

 I can agree with him: I studied and used spring dm-server and OSGi in deep (some year agoo);

I appreciated SpringSource's efforts in order to simplify OSGi, but they could not do more: the technology is too complicated and modularity is not the target for the 80 % of java/j2ee apps.

I don't know why the technology is too complicated: is it the technology itself or the problem is not solvable with a simple solution?

My take on the discussion is that with simple problems and projects, needlessly using OSGi would be an added complication that just isn't justified. But on more complicated projecs, OSGi is a technology that can be used to greatly simplify them. 

Glassfish and JDeveloper? They swear by OSGi, and the performance impact on their software is palpable.

I actually think business applications that use osgi is akin to code smell for the architecture. Most likely there are other dysfunctional issues that don't involve technology.

good technology solves the right problem but too complicated and not much traction. ?

also can j2ee spec be changed around class loading out of box ?

all this round about way of going into manifest for dependency etc isnt easy. why cant SUN/ORACLE change the class loading of jvm and provide facility to load different versions.  

This is a helpful clarification, though Rod still has it backwards in my opinion. Think for a moment about what a "complex application" means. Is the application YOU are developing not complex? How are you supposed to decide whether you have "stringent" modularity requirements, or just ordinary ones?

What Rod calls "typical business applications" are amongst the largest and most complex software projects! To suggest that they don't need modularity, while products like WebSphere, Glassfish, JDeveloper etc do, stretches credulity. Worse, the typical business application is usually developed by programmers of much more variable quality than those assigned to work on vendor products.

Now as I said in my comment on the original thread, I agree with Rod that productivity is not yet as high with modular development as it should be. Also, there are some projects -- small, simple ones -- where modularity is unnecessary. However it's clear to me that modular development techniques are already more productive than the typical "big ball of mud" architecture, into which non-modular projects inevitably degenerate. That's why vendors like IBM and Oracle have adopted OSGi. With the tools getting better all the time, it is only a matter of time before modular development with OSGi is considered more productive and more manageable than old-style flat classpath development.

This is a helpful clarification, though Rod still has it backwards in my opinion. Think for a moment about what a "complex application" means. Is the application YOU are developing not complex? How are you supposed to decide whether you have "stringent" modularity requirements, or just ordinary ones?

I've written plenty of applications that are both modular and not complex. There are a number of tools to achieve modularity: A modular build, webapps and shared web services solve 99.9% of people's modularity needs. It's not complex and it really shouldn't require too much thought or worrying about.

What Rod calls "typical business applications" are amongst the largest and most complex software projects! To suggest that they don't need modularity, while products like WebSphere, Glassfish, JDeveloper etc do, stretches credulity. Worse, the typical business application is usually developed by programmers of much more variable quality than those assigned to work on vendor products.

I don't think that anyone is suggesting that applications not be modular. It's just that we don't need OSGi to do that and it gets in the way. Having a shared artifact in a maven repository that other builds can reuse is what most people end up needing. They don't need to replace a single jar at runtime on the fly.

Now as I said in my comment on the original thread, I agree with Rod that productivity is not yet as high with modular development as it should be.

I don't think it's ever really possible for it to be, it just places too much burden on developers.

Also, there are some projects -- small, simple ones -- where modularity is unnecessary.

modularity != OSGi.

However it's clear to me that modular development techniques are already more productive than the typical "big ball of mud" architecture, into which non-modular projects inevitably degenerate.

Somehow the customers I visit manage not to have a big ball of mud. Maybe it's that I'm in the middleware space, but I tend to see a natural progression. Project starts of small, project grows, project gets refactored into different build artifacts or different services that different teams use.

That's why vendors like IBM and Oracle have adopted OSGi. With the tools getting better all the time, it is only a matter of time before modular development with OSGi is considered more productive and more manageable than old-style flat classpath development.

I'll wager you a beer that in 3 years OSGi development will still be more unproductive than regular flat classpath development. :-)

Dan Diephouse

MuleSoft

Well said Dan. I think there is a difference between modularity and separation/segregation using standard language constructs (interfaces, layers, SOLID) and a modularity platform. You can go a long way without OSGI unless of course, you are building an app server, or ide, or platform. Most business applications that I have seen, don't need osgi. In some cases, I've seen pretzel twists with Java and Spring DM that could easily be done with 1/100th the amount of code in Drupal.

This is a helpful clarification, though Rod still has it backwards in my opinion. Think for a moment about what a "complex application" means. Is the application YOU are developing not complex? How are you supposed to decide whether you have "stringent" modularity requirements, or just ordinary ones?

I've written plenty of applications that are both modular and not complex. There are a number of tools to achieve modularity: A modular build, webapps and shared web services solve 99.9% of people's modularity needs. It's not complex and it really shouldn't require too much thought or worrying about.

What Rod calls "typical business applications" are amongst the largest and most complex software projects! To suggest that they don't need modularity, while products like WebSphere, Glassfish, JDeveloper etc do, stretches credulity. Worse, the typical business application is usually developed by programmers of much more variable quality than those assigned to work on vendor products.

I don't think that anyone is suggesting that applications not be modular. It's just that we don't need OSGi to do that and it gets in the way. Having a shared artifact in a maven repository that other builds can reuse is what most people end up needing. They don't need to replace a single jar at runtime on the fly.

Now as I said in my comment on the original thread, I agree with Rod that productivity is not yet as high with modular development as it should be.

I don't think it's ever really possible for it to be, it just places too much burden on developers.

Also, there are some projects -- small, simple ones -- where modularity is unnecessary.

modularity != OSGi.

However it's clear to me that modular development techniques are already more productive than the typical "big ball of mud" architecture, into which non-modular projects inevitably degenerate.

Somehow the customers I visit manage not to have a big ball of mud. Maybe it's that I'm in the middleware space, but I tend to see a natural progression. Project starts of small, project grows, project gets refactored into different build artifacts or different services that different teams use.

That's why vendors like IBM and Oracle have adopted OSGi. With the tools getting better all the time, it is only a matter of time before modular development with OSGi is considered more productive and more manageable than old-style flat classpath development.

I'll wager you a beer that in 3 years OSGi development will still be more unproductive than regular flat classpath development. :-)

Dan Diephouse

MuleSoft

 

I agree with most of what you said but shared classloader are still a pain in the ass. I can't recall how many times I've lost a day of work because of a bizarre ClassNotFoundException and Maven transitive dependencies are sure not helping there. 

As an enterprise developer, my main need is a solution allowing my different modules to use their own isolated classloaders. That's all I care really. I want to be able to upgrade the libs used by my application modules at a different pace. Right now the only solution is to deploy each module in his own application, something that is really cumbersome when you don't need your module to be accessed remotely.

John Wells, who at the time was a senior architect at BEA (pre-acquisition), talked about why they adopted OSGi across their entire product stack. The quote I remember was this:

We thought we were doing modular development until we started using OSGi. 

It's true that you can avoid OSGi for a time by using careful development techniques, but ultimately your application will not be modular until you try it in an environment that enforces the boundaries between modules. How do you know that your "modules" are really decoupled from other modules? Hint: if you use Spring to hide dependencies in a big ball of XML and Reflection, they are not. How do you know that your modules are reusable? Unti you actually try to reuse them, they are probably not.

I'll take that bet or a richer one if you prefer. The problem will be finding somebody objective to adjudicate. Some people refuse to accept that you have made their lives easier even when presented with incontrovertible evidence of that fact.

Neil,

As you might already know, both Java SE and Java EE will bring modularity to the table in the not-so-distant future. I think it is best to see if OSGi interoperability can be achieved through that vehicle. If in the process OSGi gets sanitized/abstracted a bit, that would be good overall, correct?

Cheers,

Reza

Hi Reza. It's still very unclear when and how Java SE and EE will offer modularity, especially since the SE effort (aka Jigsaw) has gone back to the drawing board in the form of a Requirements Document -- and incidentally those requirements are very closely aligned with what OSGi offers.

Then if SE defines anything new it will take another few years to have any effect on EE. On the other hand, OSGi is here now and has already been adopted and exposed by all the major EE vendors.

For any company that regards modularity as a business benefit or even a competetive advantage -- and plenty do -- it would be stupid to wait years for EE to rubberstamp what is already the gold standard for modularity in Java.

Neil,

I'm not one to kick anyone when I think they are already down, but the point I was trying to make is that standardization via Java SE and Java EE might be one useful vehicle for working on the OSGi complexity issues folks are concerned about. In the end, OSGi containers can become the de-facto implementations for Java SE and Java EE modularity, albeit exposed through a different API/abstraction level. Oracle has significant supporters of OSGi, so this should be entirely doable.

Cheers,

Reza

Dan, very well said. I totally agree with you. modularity != OSGi. Mule is a very well designed modular product itself which I have been using happily in the last couple of years. It's not OSGi, maven has done an amazing job to help me use Mule's modular design.

Almost all of my projects, 50+ of them, big or small, are somehow modular, but none of them requires OSGi to do the job. Modular design with clear interfaces, modular build system like Maven and a well planned class loader is most what I need. I guess because I am working for projects of system integration, not a framework or toolkit.

I never required the OSGi way of hot swap of a newer modular at runtime. I have been achiving this by versioning web services and versioning workflows for some long runing processes. For typical OLTP applications, I always have to redeploy the entire application.

im ok with ROd golden age of hollywood actresses

i respected Rob Johnsons now more than ever

gift idea for designer

You are great! Wonderful compilation. I can go through the list and study them for better understanding.http://www.latestedunews.com/ http://www.latesteduinfo.com/ http://www.edu-essay.com/