The google code project released its RC2 two weeks back and boasts that the framework is currently being used on many live projects. From what I see, JCatapult, just like Spring, is a collection of frameworks. And the good thing in it is that it has the power to cater to the technological needs of even a large scale project.
Webwork has always proved that it is the best framework. Struts 2.0, therefore, cant be any better. Hibernate for ORM, Guice for dependency injection, Freemarker for templating, a brand new feature “Modules” (yet to give it a try) which enables plugging of features into the main webapplication — all sounds very good.
IMHO, there are a couple of notable differences between Spring and JCatapult though JCatapult might have an altogether different vision.
1) Spring gives more flexibility. So, you get to choose whatever set of tools/frameworks you need to use. I am really not sure how hard will it be now to switch the front end to a desktop application than Struts 2.0. I dont personally like Spring Webflow but would prefer Struts 2.0 for that. But if i really wanted to use something totally different, Spring will still make sense.
2) JCatapult should be very good for new projects considering the fact that the whole list of frameworks extensively use annotations. The ground reality is that many companies still use Java 1.4 compliant web/application servers. Spring, on the contrary, still supports 1.4 and becomes a first class candidate for “pluggable” modules of the already existing applications.
But still, JCatapult is just in its release candidate and it is not fair enough to compare it with a more mature framework like Spring. The documentation also gives us clues that it will support more and more frameworks in the future.
But isn’t it “reinventing the wheel”?
Tags: comparison, jcatapult, spring
June 6th, 2008 at 2:29 pm
This is a decent comparison. The other major difference between the two is that JCatapult lacks configuration. This can be a huge win in terms of productivity and maintenance. No XML and in most cases JCatapult will discover your Guice modules and wire things up automatically.
The other way to look at it is that JCatapult never relies on JCatapult. This is a huge distinction between light-weight and heavy-weight frameworks. It would be trivial to wire up the JCatapult email services into a Spring application. Furthermore, it would be simple to integrate the JCatapult security into a JSF application. If you consider many of Springs approaches to development, each of their technologies assumes you are using Spring and then begins to depend on many internal workings of Spring’s container. This makes it impossible to reuse those technologies without Spring. Classic example of this is Spring Security (formerly ACEGI). This uses so many hooks, conversions, lifecycle methods and much more, that only exist in Spring it can’t be used pulling Spring along for the ride.
Spring is no longer a lightweight container, it is a heavy-weight platform and is beginning to show its age. JCatapult takes the direct opposite approach by providing lightweight services and minimal glue it leans on the underlying frameworks for nearly everything. In most cases the features JCatapult provides could be achieved without JCatapult there. This means it is extremely lightweight. The reason you should use JCatapult is that writing glue code is tedious and costly. We’ve already do the hard work, might as well take advantage of it.
June 7th, 2008 at 8:42 am
Struts 1.x made XML configuration famous and Spring exploited it (sorry for my bad selection of word). As the project grows, the very thought of editing XML becomes “Ah. Not that file again !!!”.
A year ago, I fell in love with Stripes — the non-XML Struts which also provided the retro compiler which enabled porting applications to 1.4 compliant containers. But nobody bought it (at lease my project manager didnt).
I am looking forward to see JCatapult become framework of choice. I also wish that it doesnt grow heavyweight into Spring.
June 11th, 2008 at 3:51 am
XML Configuration, is the most important feature provided by Spring. This is what gives code modularity, reusability & application deployability/ configurability without all the ‘glue code’ and boiled-horse of yester-year.
ACEGI and WebFlow are not Spring, nor core to Spring, nor do they appear to particularly well or effectively follow Spring’s design philosophy.
Avoid ACEGI, it’s severely flawed.
Does very little useful, & does that poorly.