In my last blog, I described a set of criteria which can be used to determine how lightweight a framework or technology is. Let's consider Impala against the criteria described above:
1. How much system resource does the technology use?
Impala adds an almost negligible overhead to a plain Spring application.
2. Do applications need special runtime support to run?
Impala simply runs on the JVM. It's only runtime dependencies are Spring and logging libraries.
3. Are any special build steps required for the application?
No, it can be run from within Eclipse without any build steps.
4. How difficult is it to test applications which use the technology?
The interactive test runner and integration test support make Impala applications easy to test in a very productive way.
5. Can applications be updated dynamically, or do updates require a restart?
Yes.
6. How easy is it to modularise applications which use the technology?
Modularity is built in from the ground up.
7. Do applications require any code generation, either source code or byte code?
None, other than that which is used in the equivalent Spring application.
8. How quick are applications to start?
Not perceptibly slower to start initially than the equivalent plain Spring application, but requiring dramatically fewer restarts.
9. How complex is the technology to understand?
Impala is simple to understand. The developer only needs to have a understanding of the basic principles, architecture and project conventions to get going. Only in very few places is interaction with Impala APIs required.
10. Is any special tool support required to be productive with the technology?
Impala works in a vanilla Eclipse installation without any additional required plugins.
Overall, I'd argue that Impala passes this lightweightness test with flying colours. I'm also pretty convinced that an equivalent comparison with alternative technologies would be less favourable.
See more details on these definitions for lightweightness.
Sunday, May 25, 2008
What makes a technology lightweight?
What makes a technology lightweight? Being lightweight is considered a good thing. Lightweight technologies are popular with developers because they are simpler and less cumbersome to work with. The downside, of course, is that lightweight technologies can be less feature rich than their more "heavyweight" alternatives. Whether this matters depends on whether the missing features are actually required, that is, whether the value that these features provides outweigh the overhead that is added.
Plenty of technologies are "sold" on the basis of being lightweight. While most of us have an intuitive idea of what lightweight means, it's quite useful to think of this concept in terms of a more concrete set of questions or criteria. This can be helpful in making comparisons between frameworks and technologies, and indeed for assessing claims made on behalf of particular technologies.
1. How much system resource does the technology use?
This is the most obvious measure of how heavyweight a technology is. What is the memory footprint of an application? A more narrow definition of lightweight vs heavyweight technology is most likely to focus on this aspect of the definition.
2. Do applications need special runtime support to run?
If the technology requires special runtime support, then it automatically becomes more heavyweight. A good example is EJB 2, which requires applications to be run and tested in a container. Even if the container is embeddable in a standard JVM (for example within the IDE), this can make it more difficult to test applications, particularly if tests themselves need to run within the container interactive with the code under test.
3. Are any special build steps required for the application?
If the technologies require artifacts to be packaged in a certain way, then this adds an overhead to the build cycle. A related question is, can applications be run directly in an IDE without an explicit build? The most lightweight technologies by this definition require no build steps at all - you simply fire up the application in your IDE.
4. How difficult is it to test applications which use the technology?
If a technology requires special runtime support (see 2.) or it is complex to set up dependencies for running tests, the barrier to writing effective integration tests is raised, resulting in a reduction in productivity and/or quality.
5. Can applications be updated dynamically, or do updates require a restart?
If every change made requires an application restart, this can make the technology feel more heavyweight, especially if restarts are time consuming.
6. How easy is it to modularise applications which use the technology?
Technologies which allow applications to be packaged and run in a modular way will feel more lightweight than those which require everything to be run up as an amorphous "blob", especially as the application grows in size and the need to be more fine-tuned about what is deployed becomes more obvious.
7. Do applications require any code generation, either source code or byte code?
Applications which require code generation generally involve extra build steps which can complicate the build process and/or slow down the build/test cycle. Byte code generation can hide much of this pain, but does introduce a measure of complexity which can make a technology feel heavyweight.
8. How quick are applications to start?
Technologies that are slow to start are clearly more heavyweight - they are doing more, have more going on behind the scenes, and are using more memory. They also are more likely to leave behind the perception that they are inefficient.
9. How complex is the technology to understand?
The more complex a technology is, the more heavyweight it will feel. One way of thinking of it is this: for each step you take in working with the technology, the more time you will need to spend thinking about what you are doing, relative to simply doing.
10. Is any special tool support required to be productive with the technology?
If special tool support is required to make you productive with a technology, then this technology will feel more heavyweight than one which imposes no such requirements. Now, not only do you need to worry about dependencies in your runtime environment, you need to worry about those in your tooling environment. Also, its slower to get going with the technology to start with.
You can take this methodology further by ranking frameworks and technologies on a scale of 1 to 10 on each of these points. Some frameworks and technologies which purport to be lightweight are actually considerably less so when evaluated against these criteria.
In my next blog, I will evaluate Impala's lightweightness against these criteria.
Plenty of technologies are "sold" on the basis of being lightweight. While most of us have an intuitive idea of what lightweight means, it's quite useful to think of this concept in terms of a more concrete set of questions or criteria. This can be helpful in making comparisons between frameworks and technologies, and indeed for assessing claims made on behalf of particular technologies.
1. How much system resource does the technology use?
This is the most obvious measure of how heavyweight a technology is. What is the memory footprint of an application? A more narrow definition of lightweight vs heavyweight technology is most likely to focus on this aspect of the definition.
2. Do applications need special runtime support to run?
If the technology requires special runtime support, then it automatically becomes more heavyweight. A good example is EJB 2, which requires applications to be run and tested in a container. Even if the container is embeddable in a standard JVM (for example within the IDE), this can make it more difficult to test applications, particularly if tests themselves need to run within the container interactive with the code under test.
3. Are any special build steps required for the application?
If the technologies require artifacts to be packaged in a certain way, then this adds an overhead to the build cycle. A related question is, can applications be run directly in an IDE without an explicit build? The most lightweight technologies by this definition require no build steps at all - you simply fire up the application in your IDE.
4. How difficult is it to test applications which use the technology?
If a technology requires special runtime support (see 2.) or it is complex to set up dependencies for running tests, the barrier to writing effective integration tests is raised, resulting in a reduction in productivity and/or quality.
5. Can applications be updated dynamically, or do updates require a restart?
If every change made requires an application restart, this can make the technology feel more heavyweight, especially if restarts are time consuming.
6. How easy is it to modularise applications which use the technology?
Technologies which allow applications to be packaged and run in a modular way will feel more lightweight than those which require everything to be run up as an amorphous "blob", especially as the application grows in size and the need to be more fine-tuned about what is deployed becomes more obvious.
7. Do applications require any code generation, either source code or byte code?
Applications which require code generation generally involve extra build steps which can complicate the build process and/or slow down the build/test cycle. Byte code generation can hide much of this pain, but does introduce a measure of complexity which can make a technology feel heavyweight.
8. How quick are applications to start?
Technologies that are slow to start are clearly more heavyweight - they are doing more, have more going on behind the scenes, and are using more memory. They also are more likely to leave behind the perception that they are inefficient.
9. How complex is the technology to understand?
The more complex a technology is, the more heavyweight it will feel. One way of thinking of it is this: for each step you take in working with the technology, the more time you will need to spend thinking about what you are doing, relative to simply doing.
10. Is any special tool support required to be productive with the technology?
If special tool support is required to make you productive with a technology, then this technology will feel more heavyweight than one which imposes no such requirements. Now, not only do you need to worry about dependencies in your runtime environment, you need to worry about those in your tooling environment. Also, its slower to get going with the technology to start with.
You can take this methodology further by ranking frameworks and technologies on a scale of 1 to 10 on each of these points. Some frameworks and technologies which purport to be lightweight are actually considerably less so when evaluated against these criteria.
In my next blog, I will evaluate Impala's lightweightness against these criteria.
Wednesday, May 21, 2008
JavaWUG BOF 37: talk on Impala Framework
Just a quick update on my talk at the Java Web User Group in London last night. Thanks for those who made - as always it was an enjoyable evening.
Here's a copy of the presentation.
A main focus of my presentation was a demo based on an Impala version of the Spring Petclinic application - one of the main reference applications bundled with the Spring Framework.
During the demo I introduced a new feature to the application, involving a new database table, some new Hibernate mappings, persistence code, as well as some enhancements to the web presentation layer. The changes were made without having to restart the application during the demo, all updates were made on the fly.
The source code for the demo is available from the Impala subversion repository. The changes made during the demo are in this file.
Here's a copy of the presentation.
A main focus of my presentation was a demo based on an Impala version of the Spring Petclinic application - one of the main reference applications bundled with the Spring Framework.
During the demo I introduced a new feature to the application, involving a new database table, some new Hibernate mappings, persistence code, as well as some enhancements to the web presentation layer. The changes were made without having to restart the application during the demo, all updates were made on the fly.
The source code for the demo is available from the Impala subversion repository. The changes made during the demo are in this file.
Friday, May 16, 2008
Talk next Tuesday on Impala at JavaWUG
Next Tuesday evening I am doing a talk on Impala in London. Here are the details:
http://www.jroller.com/javawug/entry/javawug_bof_37_impala_framework
You can register for the event here:
http://skillsmatter.com/event/java-jee/javawug-bof-37
The talk is at 6:30pm at Skills Matter in London. I'll be explaining why I created Impala, how it can dramatically accelerate Spring-based development and allow you to create more modular, maintainable applications. The format will a mixture of slides and demos.
http://www.jroller.com/javawug/entry/javawug_bof_37_impala_framework
You can register for the event here:
http://skillsmatter.com/event/java-jee/javawug-bof-37
The talk is at 6:30pm at Skills Matter in London. I'll be explaining why I created Impala, how it can dramatically accelerate Spring-based development and allow you to create more modular, maintainable applications. The format will a mixture of slides and demos.
Saturday, May 10, 2008
Impala 1.0M1 released - first public release
I am pleased to announce the first public release of Impala, a dynamic module framework for Java enterprise application development.
Impala 1.0 M1 can be downloaded from http://code.google.com/p/impala/downloads/list
Impala builds on the Spring Framework to provide a genuinely modular, highly productive environment for web-based applications. It allows you to divide Spring-based applications into a hierarchy of modules which can be dynamically added, updated or removed to an existing running application.
Impala's modularity features make it possible to write applications which are much easier to maintain than plain Spring applications. Impala enables applications which can grow very large without exploding in complexity. Impala also enables genuine productivity enhancements over plain Spring development, through the dynamic module loading capability, seamless integration with Eclipse, and the efficient test management features. Impala also features basic built-in build support, based on ANT, and dependency management capabilities.
With Impala, you can take your Spring application development to the next level without having to grapple with any unfamiliar underlying technologies or tool sets. It requires no additional third party libraries beyond those required for plain Spring applications. It works within existing Java deployment environments, and requires no complex runtime infrastructure or tool support.
For more information on getting started with Impala, see http://code.google.com/p/impala/wiki/GettingStarted.
Impala 1.0 M1 can be downloaded from http://code.google.com/p/impala/downloads/list
Impala builds on the Spring Framework to provide a genuinely modular, highly productive environment for web-based applications. It allows you to divide Spring-based applications into a hierarchy of modules which can be dynamically added, updated or removed to an existing running application.
Impala's modularity features make it possible to write applications which are much easier to maintain than plain Spring applications. Impala enables applications which can grow very large without exploding in complexity. Impala also enables genuine productivity enhancements over plain Spring development, through the dynamic module loading capability, seamless integration with Eclipse, and the efficient test management features. Impala also features basic built-in build support, based on ANT, and dependency management capabilities.
With Impala, you can take your Spring application development to the next level without having to grapple with any unfamiliar underlying technologies or tool sets. It requires no additional third party libraries beyond those required for plain Spring applications. It works within existing Java deployment environments, and requires no complex runtime infrastructure or tool support.
For more information on getting started with Impala, see http://code.google.com/p/impala/wiki/GettingStarted.
Monday, May 5, 2008
Spring Application Platform validates Impala's existence
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.
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.
Friday, May 2, 2008
Spring Application Platform - is it a big mistake?
It was with some consternation that I read the Server Side thread on Spring's announcement of a new application platform.
Firstly, the Spring Application Platform, as it's called, is essentially a Spring OSGi integration on steroids. I've voiced concerns on how well OSGi is going to be received by ordinary developers, as against application server vendors. I'm yet to be persuaded that regular
Java developers will be particularly enthusiastic about dealing with the idiosyncracies of OSGi. There is more than a hint of EJB history about it. SpringSource (and application server vendors?) have identified OSGi as the way that we ordinary mortals must now follow.
Spring Application Platform (and Spring Dynamic Modules) are great if you've already bought into OSGi. As a general platform for enterprise application development - at this point I'm yet to be convinced.
Secondly, with its Application Platform, SpringSource has moved squarely into the application server market. This is something which I didn't expect them to do, and I don't think it's a very good idea. It's too invasive, too big a step in one particular direction for me to feel comfortable with. I think of the Spring Framework as a technology which works seamlessly with a broad variety of platforms and application servers. With the Application Platform, they're pinning their colours to a particular mast - a technology stack based on Equinox and Tomcat, and setting themselves in competition with other application servers.
Thirdly, there is the question of the license. For the first time, SpringSource is introducing a major product which is not based on the Apache V2.0 license, instead going for a GPL license. That's a major change that reflects a real difference in the way that the company is positioning itself in the marketplace.
Finally, the question in my mind is where the Spring Framework itself fits into all of this. I've always thought of the Spring Framework as the flagship product coming from the Rod Johnson crew. It didn't matter if SpringSource came up with one or two turkeys in its portfolio, because at least the core framework is solid. But with the Spring Application Framework, they're betting big. They've clearly had some of their best brains working on the project for some time. A failure won't be quite as easy for the development community to brush off.
So what will happen now? Will the Spring Framework become the "poor relation" of the Application Platform? Will new features and improvements go into the Spring Framework, or will this suffer in the future at the expense of the Application Platform. The waters have definitely been muddied.
The Spring Application Platform is the biggest announcement to come out of the Spring team for some time. It also looks like it could be a big mistake. Spring became popular in the first place as a practical, community driven solution to the real problems with Java enterprise applications, with a focus on simplicity. The latest offering seems to be moving in a rather different direction.
Firstly, the Spring Application Platform, as it's called, is essentially a Spring OSGi integration on steroids. I've voiced concerns on how well OSGi is going to be received by ordinary developers, as against application server vendors. I'm yet to be persuaded that regular
Java developers will be particularly enthusiastic about dealing with the idiosyncracies of OSGi. There is more than a hint of EJB history about it. SpringSource (and application server vendors?) have identified OSGi as the way that we ordinary mortals must now follow.
Spring Application Platform (and Spring Dynamic Modules) are great if you've already bought into OSGi. As a general platform for enterprise application development - at this point I'm yet to be convinced.
Secondly, with its Application Platform, SpringSource has moved squarely into the application server market. This is something which I didn't expect them to do, and I don't think it's a very good idea. It's too invasive, too big a step in one particular direction for me to feel comfortable with. I think of the Spring Framework as a technology which works seamlessly with a broad variety of platforms and application servers. With the Application Platform, they're pinning their colours to a particular mast - a technology stack based on Equinox and Tomcat, and setting themselves in competition with other application servers.
Thirdly, there is the question of the license. For the first time, SpringSource is introducing a major product which is not based on the Apache V2.0 license, instead going for a GPL license. That's a major change that reflects a real difference in the way that the company is positioning itself in the marketplace.
Finally, the question in my mind is where the Spring Framework itself fits into all of this. I've always thought of the Spring Framework as the flagship product coming from the Rod Johnson crew. It didn't matter if SpringSource came up with one or two turkeys in its portfolio, because at least the core framework is solid. But with the Spring Application Framework, they're betting big. They've clearly had some of their best brains working on the project for some time. A failure won't be quite as easy for the development community to brush off.
So what will happen now? Will the Spring Framework become the "poor relation" of the Application Platform? Will new features and improvements go into the Spring Framework, or will this suffer in the future at the expense of the Application Platform. The waters have definitely been muddied.
The Spring Application Platform is the biggest announcement to come out of the Spring team for some time. It also looks like it could be a big mistake. Spring became popular in the first place as a practical, community driven solution to the real problems with Java enterprise applications, with a focus on simplicity. The latest offering seems to be moving in a rather different direction.
Subscribe to:
Posts (Atom)