2007/07/09

Java with Spring just as productive as a 4GL RAD tool

Java with Spring just as productive as a 4GL RAD tool
by Erwin Bolwidt and Vincent Partington
Java is known for its platform portability, its scalability, and the large number
of libaries and tools available for it. However it is oft maligned as not offering
sufficient productivity especially when compared to 4GL RAD tools or the .NET
framework. During the 2005 Dutch RAD Race we proved that Java beats the
.NET framework and measures up to the best RAD tool, without sacrificing
quality and flexibility.
The contest consisted of the development of an administrative application for a fictional
travel agency in two days. Apart from numerous data entry screens, the application had
to invoke a web service, expose a web service, provide management reports in a
number of formats (Excel, HTML) and there was some complicated logic like searching
for a flight schedule.
We produced a full working application in two days by using new frameworks like Spring
and Hibernate, proving that Java can be as productive as any other environment. In
this article, we explain what tools we used, what went well and what went wrong.
So what libraries and tools did we use?
The most important software we used was:

Spring Framework 1.1.3

Eclipse IDE 3.1M4 with Eclipse Web Tools Platform 1.0M3

Hibernate 2.1.7

Hibernate Synchronizer Eclipse plugin 2.3.1

Tomcat 5.5.4

MySQL 4.1
On top of that, we prepared by designing a template/starter application using these
tools. For the GUI, we made extensive use of tag files we created ourselves. Tag files
are a JSP 2.0 feature.
How did these things help us?
One thing that stands out is the non-invasiveness of the tools. Neither the IDE nor the
libraries rigidly forced us in a direction thereby making it easier to combine them.
During the race, we had to extend the domain model and the database a few times.
Hibernate is a great OO mapping tool, but the Hibernate Synchronizer is what helped us
here the most. It takes a sensible approach by generating and re-generating
superclasses for your domain model, so you can add your OO logic to the subclasses
without having to worry about your code being modified or deleted after regeneration.
Compare the BaseTrip class generated by the Hibernate Synchronizer to the Trip class.
The latter contains additional business logic to calculate trip prices and apply discounts.
We used Spring Web MVC for the web interface. One of its prime advantages in rapid
development is that it allows your domain objects (which were generated by the
Hibernate Synchronizer) to be used directly as command objects in form controllers; no
separate "form object" is required, reducing code duplication. See the EditTripForm
class.Page 2

We also used the "open session in view" interceptor, which allows the views,
implemented as JSP's, to access lazy associations in the domain model by retaining a
read-only hibernate session during JSP rendering. We didn't have time to analyse the
performance impact this would have in a production application, but it is a really handy
pattern during rapid development, and can always be rewritten by putting more
complexity in the DAO during an optimization sweep over the application.
The biggest advantage of the Spring framework is how it allows the application to be
'componentized'. The IoC-based XML configuration of components makes team
development a real breeze, which is extremely important when you're quickly building
an application with a team, since you tend to get into each others hair all the time. It's
really a matter of defining an interface, letting one developer use it and another
developer implement it. If the implementation takes too long, implement a simple stub
version of it to test the client against; a simple change in one xml file rewires the
application against the correct implementation whenever that is needed.
For example, in this Spring bean configuration the real temperature report that invokes
the web service is wired in:
class="com.xebia.teltravel.bizlogic.TemperatureReportImpl">




However, by changing those lines to the following, a fake implementation can be used
that does not require access to the webservice:
class="com.xebia.teltravel.bizlogic.FakeTemperatureReportImpl"
/>
One caveat: it is important to split up the XML files, either logically based on application
layers, or based on team members; the latter is preferable during rapid development to
reduce the number of CVS merge actions.
Finally, Eclipse is a flexible IDE with a plethora of available plugins to make it even
better. Apart from the Hibernate Synchronizer already mentioned, we used the Web
Tools Platform to integrate Tomcat very closely, allowing us to start the application in
ten seconds on our 3GHz Pentium IV, 1GB laptops. No EJB layer means there are no
deployment cycles and that the application server starts up quickly. The close
integration with Eclipse meant we could debug on source level. When making a change
we had the choice of letting the JVM modify the class on-the-fly, restart the application
or restart the application server. All this gave us quick turn-around on our change.
To summarize, we believe these to be the strong points that benefited us most:
 Easy team development because of component separation,
 Fast and powerful assembly of our own code and third party components (such
as Hibernate, Axis, etc.) into the application using the Spring Framework,
 Easy fit of third party libraries into the application, and
 Having a skeleton application (based on the Spring PetClinic sample), including
a consistent skeleton GUI, available to bootstrap the project from.Page 3

Weak points
To be honest, we did run into some problems.
The biggest problem was the speed at which we could build the user interface. Despite
having a skeleton GUI and customized JSP tag files, this took us significantly more time
than other teams that worked as fast as we did. Time that could have been spent on
completing more parts of the assignment and on better peer review of the code. A
faster solution for this problem would have given us the edge, and victory. But alas, we
didn't have or know a good solution that fits into the toolset that we are using.
What we envision as a solution is a flexible approach, using the same principles as the
Spring Framework.

No code generation during the build phase

Form rendering with minimal configuration, using introspection on domain
objects to find as much information as possible

Open, pluggable architecture where all components can be replaced or
customized

Should place little or no requirements on application architecture
Another issue is the time is takes to propagate changes through layers. Although its
impact is less profound than that of the GUI problem, and despite the re-use of domain
objects for web forms, it is still necessary to make changes to the application in
multiple locations for some types of changes. Mainly those in the domain model.
Smarter plugins for the IDE may alleviate this problem, but in a layered application,
this problem will probably always remain to some degree.
Conclusions
Out of the 9 contestants, we came up third. Visual Studio .NET came in eighth place,
and Java with a traditional toolset came in seventh. A 4GL tool called Magic e-
Developer came first, and an Oracle toolset second, the first three positions within 10%
of each other.
Java can be really productive right now. It can equal the productivity of 4GL tools that
are specifically designed for rapid application development and outpace .NET which is
regularly touted as being more productive than J2EE.
Spring allows for greater modularization because of Inversion of Control and its non-
invasive approach. The basic concepts of Spring are simple and consistently
implemented, making it easy to learn enough of Spring to be productive in a short
period of time.
Hibernate, especially combined with the Hibernate Synchronizer plugin, is a quickly
implemented and dependable solution for data access, and works well in tandem with
Spring Web MVC.
Finally, it's more fun to develop in parallel and being able to present working versions
of an application so soon in the development process.
These tools provide a significant improvement over 'plain Java'. Our score was more
than twice that of the 'plain Java' and 'plain .NET' entries. In previous years of the
competition, Java consistently ended in the bottom half of the results. Our personal
experience also indicates that we are much more productive with the combination of
Spring, Hibernate and Eclipse than with a 'plain J2EE' approach.Page 4

About the authors
The authors of this article, Vincent Partington and Erwin Bolwidt, are the team that
participated in the Dutch Rad Race 2005 for Xebia. They are J2EE consultants for Xebia
and each have more than 8 years experience in software engineering with Java and were
involved with server-side Java technology for nearly as long

No comments: