orting an existing Java Web application to a new framework is probably not at the top of most developers' fun-stuff-to-do lists. In addition to the time of learning a new Web framework, the tedious process of converting things like tags, internationalization systems, and validation can force even the most courageous among us to think twice. I recently faced such a challenge when considering a move from Struts.

The first question in any decision about porting an application should be "Why not stay with the framework I have?" In my case, Struts was a stable, well-documented framework with a large developer community, but configuration was cumbersome and the separation of forms, actions, application flow, and validation sometimes made following a thread through an application like trying to untangle a knotted fishing line. This tendency only got worse as my Struts applications grew. Eventually, from a maintenance perspective alone, migrating to a new framework made sense.

None of the frameworks I first considered (Java ServerFaces, Tapestry, WebWorks, Spring MVC) convinced me that their potential benefit outweighed the cost of porting from Struts. Some, like JSF, were not view friendly. Others, like Tapestry and WebWorks, had per-page internationalization systems that looked cumbersome. And Spring MVC didn't look much better than Struts from a configuration perspective. The framework I selected needed to justify the time spent learning it and the effort of actually porting the code; it had to take me to a better place—a place where code was easier to write, troubleshoot, and maintain. From that perspective, these alternatives looked more like tradeoffs than saviors.

Stripes to the Rescue!

Then I happened upon the Stripes Framework. Like many in the Java community, I had been following the Ruby on Rails (RoR) phenomenon. For me, Stripes was the closest of the Java MVC frameworks to the RoR philosophy: simple, elegant, and requiring minimal configuration. In addition to its simplicity, Stripes looked familiar to a Struts veteran like me. The application flow and many of the naming conventions were similar. Stripes' ActionBeans were like Strut's Actions, and ForwardResolutions looked a lot like ActionForwards. With this framework, I would not have to throw away all of my hard-earned Struts knowledge.

Something else that appealed to me was the Stripes documentation. Like the framework itself, it was clear, clean, and concise. The tag library docs and API were well documented, and just about every feature of the framework had sample code. This excellent documentation, along with the ability for me to capitalize on my existing Struts knowledge made me confident I could quickly get up to speed with the Stripes framework.

Stripes also contained features that made it a good AJAX platform, including a streaming resolution that allows for improved error handling in AJAX implementations. For me, however, the deciding factor ultimately was that I could clearly see it making my life easier. I estimated that I could reduce the total lines of code in the action/configuration/validation areas of my application by about half. Less code meant fewer bugs, faster development time, and easier troubleshooting.