Choosing between Impala and OSGi

Question

I've been investigating OSGi for my company's software, but have recently been recommended to take a look at Impala. According to its web page, Impala is "a dynamic module framework for Java-based web applications, based on the Spring Framework."

At a glance, and looking at this blog post about the differences, the key differences I can see are that Impala is simpler than OSGi, does not manage versioning of third party components, and is far less widely used/known (I do not see a single question about it on Stack Overflow).

I wonder whether people who have direct experience with Impala and OSGi (i.e. those who have investigated it more deeply than reading blog posts and online docs), have any more insights into the practical differences between the two, and/or suggestions about what types of projects each one may be more or less suitable for.

Edit: It may also be interesting to include Springsource Slices into the comparison, although it is as yet an early prototype. At a glance, it appears to only work in DM Server.

Answer 1

In my eyes, there is no comparison. OSGi is a mature framework that's been around for 10 years and is the basis for the implementation of most of today's Java containers. OSGi has growing adoption, there are books available and, yes, people talk about it on Stack Overflow!

Impala hasn't even hit a stable release and appears to be a 1-man project, though he is asking for additional developers now.

So, it depends on your criteria. If you are investigating technology out of interest, then I don't see any issue writing stuff with Impala. If you are looking to base your company's future products on it, then I think that would be professionally negligent.

Answer 2

Impala's approach to modularity is very weak when it comes to controlled sharing between modules. The problem is that Impala still follows the old J2EE-style hierarchical approach to classloading.

Anybody can write a module system that restricts visibility of classes across modules. The difficult part is how you reintroduce dependencies between modules such that specific classes and interfaces from one module can be seen by another module. In OSGi we do this by exporting and importing packages, so we have a non-hierarchical dependency graph.

In Impala, if you want to see the classes in another module, then your module must be a child or descendant of that module. That is, modules can only see their own classes and those of their ancestors. Now if you want to share some classes with your sibling module (e.g. a library that you both use) then you must move that library up into the classpath of your shared ancestor. In the worst case you have to move it right up to the root module. Now the library is visible to ALL other modules whether they want it or not! Indeed, if another module wanted to use a different version of the library they would be prevented from doing so.

If you simply have a copy of the library in each place where it is used, then you make it impossible for the modules using that library to communicate with each other. They will get ClassCastExceptions when they try to pass objects between each other.

A similar problem is inherent in J2EE if two web applications need to use the same library. Typically J2EE developers just copy the library, but this creates "silo" applications that cannot communicate with each other. It is simply not the way to build modular software.

Steven's points also seem pertinent. As far as I can tell, nobody is using Impala aside from its author.

Answer 3

Neil,

You seem to spend a lot more time smearing Impala than you spend understanding it. This time you have outdone yourself - all your points are wrong this time.

Impala does use by default a graph-based approach to class loaders, so that you can structure your modules in a way that suits the needs of arbitrary applications.

Regarding ClassCastExceptions - I simply never get these in my applications, and I have not received a single report from a user complaining of ClassCastExceptions down to classloader issues.

You repeatedly say that no-one is using Impala. Downloads for the last year are consistently 100+ a month level - not exactly mass market but to give at least some of the benefits of making the project available to the open source community.

Phil Zoio

http://www.impalaframework.org/