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.
3 comments:
Actually, if you don't need multiple versions of third party libraries loaded concurrently within the same JVM then you could just add those packages to the OSGi bootdelegation system property and put the jars on the main classpath.
You'd avoid hairy classloader issues, and those libraries would then get the parent classloader delegation that they (may) expect.
You'd also be free to move to the more dynamic model later on if you wanted to, because you're still coding to the OSGi standard.
But it's always interesting to see new ideas of modularizing Java apps, so good luck with Impala!
(PS. the often quoted third-party library where support for multiple versions can be very useful is the XML support found in modern JDKs)
I am very encouraged by your approach and will be trying out impala. I will be starting as an archi-techy at a company which is just now getting rolling with spring, and some lead developers are very enthusiastic about osgi as well (my guess is that they are jumping on the spring application platform even as we speak.. oh boy). I just can't share this enthusiasm. I agree that the big issue is modularity and osgi just seems way too heavyweight and invasive a solution for providing something as fundamental as modularity. I started wondering if I could build my own framework using java classloading and spring framework mechanisms, and quickly stumbled across impala... If it works like you say, there is a good chance that I will 'decree' (power is a wonderful thing :-) impala to be the lightweight osgi-killer at my new shop...
John, Good luck in your new role. I've tried to make it clear that I am not anti-OSGi, but that it's not for everyone. I intend to make Impala more OSGi friendly. There is no reason, for example, why Impala shouldn't be able to run on the Spring App Platform. The key point is that mandating OSGi is not the right approach, because it's not right for every project. It's probably better suited for big budget projects with long inception times and intended longevity, that's hardly the case on every project.
Post a Comment