A couple of days ago I wrote a blog in which I was somewhat negative about the Spring Application Platform. My issue is partly with the problems SpringSource is trying to solve, and also the way that they are trying to solve them.
The problems being targeted are twofold: first, the ability to get more precise control over which versions of which class are loaded by which libraries in the JVM, and secondly, the need for modular applications.
What I've been saying all along is that while the ability to get precise control over class versioning is worthwhile, it also involves quite a lot of pain, and for most developers, this pain will not be worthwhile.
What is really needed is modularity. SpringSource have gone straight for OSGi to achieve both modularity and class versioning. The problem is that this solution also brings is a lot of complexity. So in order to manage this complexity, an extra solution is needed to hide this complexity. Enter the Spring Application platform.
The problem with all of this is that there seems to be an implicit assumption that effective, dynamic modularity is not possible without OSGi. How about another approach? Why not try to see how far you can get with just the standard Java class loading mechanisms? Spare yourself all the hassle where it's not needed, and go straight for the sweet spot. That's the Impala approach. OSGi may come to Impala too, but it won't be forced on users.
Surprisingly, you can get pretty far without OSGi. For one, you can have multiple versions of your own applications loaded simultaneously in different modules. You can do on the fly updates. You can also get tremendous productivity advantages from simple and lightweight mechanisms for managing integration tests, with fewer restrictions on your runtime environment than you will have with OSGi.
What you don't get without OSGi is the ability to have multiple versions of third party libraries loaded concurrently within the same JVM. The question you have to ask yourself is this: how important is this feature to you? How much pain are you prepared to go to achieve it? After all, hundreds and thousands of Java applications have been written that don't rely on this feature. In my time as a Java developer, I can only think of at most a handful of occasions where class versioning issues have presented an issue. It does not seem like the kind of problem that deserves a solution with a far reaching impact on your technology choice, runtime environment and tool set.
In short, I am apparently in agreement with SpringSource that modularity and dynamic reloading are two features whose absence has been a real limitation to development using the Spring Framework. This certainly convinces me that the last year or so that I have spent working on Impala has not been a waste of time. Indeed, the benefits experience by projects I have worked on using Impala suggest the contrary.