Fresh cup of Java
Hi, all Java gurus inside and outside of Thinknostic - I have a very interesting problem. Imagine the following situation: we have three existing Java Web applications, written back in 2000/2001, based on open source libraries of that time: Struts 0.9/1.0 and JSP 1.x (no JSTL) with Tiles for Web layer, Apache Torque for ORM, early version of Quartz for job scheduling, Jasper Reports for PDF reports and Freemarker as template engine for email creation. The application has been (and still is) in production for almost 7 years and works great. Now the customer is expanding the functionality and wants add several Ajax features - in short, version 2.0 is on the table.
As part of adding new functionality, we will be updating the foundation libraries to make sure we are current with the latest and greatest mainstream libraries and frameworks and that the application will (after the enhancements) work for another 5-7 years without needing major updates. The criteria for updates of the base libraries are:
a) must be open source (preferred Apache or BSD license)
b) must be mainstream technology (availability of skills and longevity of project)
c) simple is better than complex
One pretty much given is "metaframework" which will be Spring. I have looked into some other IoC containers but did not find any compelling reason not to use Spring. The newest Google creation - Guice - looks pretty interesting (if you like annotations and hate XML) - it is much smaller and very lightweight - but as we will need many of the Spring modules anyway (besides configuration at least AOP, transaction support, events, persistence layer integration, scheduling etc), it is simpler use just Spring. Besides, Springs works great with POJO as business layer.
For data layer, I am considering replacing Torque (which evolved since 2000 and upgrading code to version 3.x would require non-trivial changes) either with most "standard" ORM mapper today - Hibernate, or (alternatively) going away from the full ORM (which is not really required) to just iBatis as thin layer on top SQL. Spring supports both Hibernate and iBatis very well. One argument for iBatis is that it makes much easier for DBA to understand and adapt SQL queries the application is using, compared to Hibernate magic and SQL generation.
On Web framework side, we will stay with latest version of JSP with JSTL and most likely use Spring MVC as UI framework. Struts 2.x is quite different from what we have used before - so staying with Struts would not be such an advantage as it may seem. The main argument for using Struts is amount of books, skilled people and availability of tools - but unfortunately, if you discount Struts 1.x and focus on Struts 2.x only, Spring is probably as good choice if not better from market share point of view (and is IMHO much more open and flexible). I was briefly contemplating using alternative view technologies (Freemarker instead of JSP) as I am not big fan of "servlets in disguise" - but both Freemarker as well as Velocity are much more niche technologies which may not be popular in 2-3 years from now.
One change that I am going to evaluate is using Sitemesh instead of Tiles - I did not worked with it yet, but the examples I tried look very promising (and Matt Raible uses it it AppFuse ;-)). Speaking of it, Matt also would not use Struts 2 :-)
The last open question is on Ajax side. My experience with Ajax framework was so far exclusively outside of Java world - either Rails (where it is amazingly simple) or in ASP.NET (where it may be easy or hard, depending on haw you do it). With Java (and Spring) there is - as usual - many options and I need to do some research and evaluation. I will get back to it. Let me know if you have any suggestions or recommendations - ideally from real life Spring MVC experience. Thanks in advance.
Author Miro Adamy
License (c) 2006-2020 Miro Adamy