The project most closely related to Impala is Spring OSGi, so it's tempting to try make some comparisons on the two projects, or at least on their approaches to solving the problems they are tackling. I should preface this by saying that I am talking from a certain position of relative ignorance: my understanding of Spring and OSGi is based mostly on what I have read in the documentation and a small amount of playing with samples some time ago. I've since been to a talk on OSGi at JavaWUG in London, and read a fair portion of the OSGi spec. I hope this has given me sufficient understanding to make a few remarks which reflect my impressions of the differences between Impala and the world of Spring OSGi.
Spring OSGi and Impala are tackling an overlapping set of problems
What Impala and Spring OSGi have in common is that they are both dynamic module based systems.
Impala provides a developer productivity solution through build support, an interactive test runner, and support for efficient, fast running integration tests.
OSGi, on the other hand, tackles a wider set of problems relating to visibility of classes. OSGi allows you to run multiple versions of third party libraries within the same JVM, which can prevent problems which may occur from different libraries depending on incompatible versions of the same third party library. You can think of OSGi as defining multiple class spaces for third party libraries as well as application code.
Impala makes a clear distinction between application code and third party libraries. There is only a single class space for third party libraries. If there is a clash between third party libraries, then you are no better off (or worse off, for that matter) than you would be in a standard Java/pre-OSGi world. You would still need to resort to whatever workaround would apply in that case.
While third party library clashes are certainly a theoretical possibility, it is quite rare in my experience to actually be a victim of such problems in a way which couldn't be addressed relatively easily through a simple workaround. Others may have different experiences in this regard. However, it does seem that there is quite a bit of overhead required to make sure that the Jars you use fit in nicely with OSGi requirements, so that they "play nicely" in OSGi world. It's the kind of overhead that I think most developers would look for ways to avoid for as long as they are able to do.
Impala provides a developer productivity solution through build support, an interactive test runner, and support for efficient, fast running integration tests.
OSGi, on the other hand, tackles a wider set of problems relating to visibility of classes. OSGi allows you to run multiple versions of third party libraries within the same JVM, which can prevent problems which may occur from different libraries depending on incompatible versions of the same third party library. You can think of OSGi as defining multiple class spaces for third party libraries as well as application code.
Impala makes a clear distinction between application code and third party libraries. There is only a single class space for third party libraries. If there is a clash between third party libraries, then you are no better off (or worse off, for that matter) than you would be in a standard Java/pre-OSGi world. You would still need to resort to whatever workaround would apply in that case.
While third party library clashes are certainly a theoretical possibility, it is quite rare in my experience to actually be a victim of such problems in a way which couldn't be addressed relatively easily through a simple workaround. Others may have different experiences in this regard. However, it does seem that there is quite a bit of overhead required to make sure that the Jars you use fit in nicely with OSGi requirements, so that they "play nicely" in OSGi world. It's the kind of overhead that I think most developers would look for ways to avoid for as long as they are able to do.
Impala has more of a focus on developer productivity
The purpose of Spring OSGi seems primarily to bring the benefits of OSGi to Java, via Spring. In that sense, it is OSGi centric. The fundamental trade-off with OSGi is one of productivity. Are you prepared to go to quite a lot more trouble in defining quite precisely the nature of dependencies between libraries, with the benefit that you will never get ClassCastExceptions due to classloader issues, and that you will be able to dynamically update library versions. Make no mistake, these benefits come at a cost. One very experienced OSGi developer described working with library dependencies OSGi as a "pain in the arse", something you wouldn't want to do without tool support.
Impala, by contrast, does not impose these kinds of constraints. In fact, it's very essence is about productivity. Dynamic module reloading can benefit productivity, because it means that integration tests can be written on the fly against a running application.
Impala Support for OSGi
Impala has all the internal interfaces necessary for seamlessly supporting OSGi, probably via Spring OSGi. I'm definitely considering adding this in the future. For the time being, that's not on the immediate horizon - getting the project into a publicly releasable form is a higher priority right now.
10 comments:
I think you're comparing apples and oranges. Impala doesn't seem to be a general purpose module system, for example the division between third-party and "application" code is arbitrary, and you admit that there can be problems with library clashes, indicating that you probably still use a flat classpath per conventional Java.
I don't mean to disparage Impala; I just think it's an inappropriate comparison.
In my opinion, if OSGi is a pain in the arse it's because true modularity is a pain in the arse! It's particularly hard to revisit existing code and introduce modularity, just because developers are sloppy and build things without proper separation of concerns etc., unless they are forced to.
The same problem exists with respect to security: it's extremely hard to make an existing body of code secure, unless it was written from scratch with security in mind. Concurrency is like this too.
With OSGi, you can appear to be less productive because you may be producing lines of code at a lesser rate. But the code you're building is guaranteed to be modular, so it is more valuable in the long run. So I think it doesn't impact true productivity.
Anyway, good luck with Impala and I'm glad you're considering supporting OSGi.
Neil thanks for your comment!
You're absolutely right in saying that Impala is not a general purpose module system. It is simply a framework which provides modularity features for Spring based applications. The comparison is not between Impala and OSGi, but between OSGi and traditional class loaders as an implementation mechanism.
I readily concede that I don't have enough practical experience writing applications based on OSGi to be able to tell exactly how much of a "pain in the arse" it actually is. I am looking forward to getting the chance to work with OSGi and introduce it to Impala. It is certainly the most robust and comprehensive general purpose modularity solution available for Java that I'm aware of.
That being said, it is possible to build modular applications that don't use OSGi. The key characteristic of modularity is the ability to divide the parts of your application into separate and separately deployable units - something which Impala offers.
If using OSGi does cause productivity to suffer, then it could be a bit of an achilles heel. You only have to look at the hype around the likes of Ruby on Rails to realise how important productivity is as a source of value of a technology.
Thanks Phil.
You're right, non-OSGi module systems do exist and can be built using ClassLoaders or whatever. But there is a danger of proliferation: how many module systems does Java need? OSGi is the closest we have to a standard module system for Java right now. It's also had 8 years of continuous refinement, so they've found most of the corner cases by now!
Like I said, I think modularity itself is hard, and if Impala is doing it properly then I would expect to see the same impact on productivity.
I do feel that productivity should be properly measured though. Ruby fans tend to dislike static typing and compilation because it hinders their productivity... but if Java developers take slightly longer to produce code that is more robust, are we really less productive? If we only measure lines of code, then a great way to get extreme productivity is to dispense with unit testing! Not even RoR developers would agree with that approach though :-)
Cheers
Neil
Neil,
I'm certainly not trying to reinvent modularity for Java applications, but just solve a particular problem - provide modularity to Spring-based applications, with some high-level abstractions for managing a hierarchy of Spring application contexts.
I don't think that the productivity that you get with Impala is at the expense of robustness - on the contrary! You get the advantages of Java static typing, but because development with Impala is very test-centric with the interactive test runner, writing the integration tests is easy. It's not at all a pain point. This can only help robustness.
Cheers,
Phil
I do not think you have modularity without strict enforcement. OSGifying existing applications is so painful because people were not modular. John Wells from BEA said it very nicely: "If you think you work modular, and you're not using OSGi, then you are not working modular." When they converted their existing "modular" codebase to OSGi they were quite horrified by the amount of unexpected coupling they found.
I am very interested how you will look at these issues 4-5 years from today when you have to support legacy code and no longer have a greenfield area ... I expect that many of the OSGi features then suddenly make a lot of sense.
Love to see your OSGi support, kind regards,
Peter Kriens
Peter,
I fully agree that you don't have modularity without fixed enforcement. I also agree that we would all be much better off if OSGi (or something like it) had been adopted from the beginning, or better still, if there was no way to write applications without this kind of strict enforcement.
That being said, the approach to taken in Impala is modular is the sense that there is strict enforcement of boundaries between modules within the application's code base. Specifically, classes in individual modules are not visible to sibling or parent modules, or to modules on different branches of the module hierarchy tree. Common interfaces are visible through shared parent modules. Cyclical dependencies are not possible across module boundaries.
In my opinion, this is a modular solution. Feel free to convince me that I'm wrong and the approach I describe is not modular.
Where Impala's approach differs from OSGi is that it does not cover third party dependencies. But because I don't need to manage the code base of third party dependencies, I'm not as concerned about this as I am about modularity of my own application's code.
You do make a good point about how greenfield application code eventually becomes legacy, and OSGi offers real advantages there, in making legacy code easier to use. That being said, notwithstanding the fact that you are not forced to adopt OSGi friendly package structure conventions, you're not in a bad position with Impala when OSGifying existing applications. This is because at least they will be free of cross module dependencies.
In spite of reservations I have expressed, I am looking forward to bringing OSGi into Impala, but I want to make sure that this is not at the expense of the more near term goals I have for the project.
Cheers,
Phil
Phil,
I am very interested about your project.
Never mind about the all-modular-systems-must-be-OSGI guys. There is plenty people with the problem for which your solution is the cheapest and most convenient one.
Best regards,
Paulo Gaspar
Hi Phil,
I understand you approach of having some legacy code and a bunch of third party jars in the environment and make some plugin jars reloadable. I find OSGi calls for a complete restructuring of the applications to be even able to get up and running.
Can I use impala for normal java application which does not use springs or any DI frameworks?
If it is possible please let me have some cues.
Samarit,
In practice you do need to use Spring. Impala is layered architecturally so that you could in theory use another DI framework, but there is only an implementation for Spring.
I don't think it would make a lot of sense to not use a DI framework at all, because the DI framework provides hooks that allow you to configure proxies to services/beans published by other modules, which you need in order to make elements of the system independently reloadable.
Post a Comment