Java Reference
In-Depth Information
Luckily, Enterprise Java had a happy ending. The POJO and lightweight container movement led
by Rod Johnson
8
gained a huge following and soon became a competitor to J2EE. Spring offered a
lightweight container and the ability to run on simple Java servers. The POJO approach was great
for testing and did not need the container most of the time, but even if the container was needed, it
was not hard to use.
The success of Spring caused a renaissance in the Java Community Process. Java EE 5 was designed
from scratch to support POJO EJB and lighter containers. Java EE had evolved and matured.
However, old habits and development techniques did not change overnight. Still, many developers follow
the patterns of J2EE, creating overly layered and complex applications while not using the lightweight
containers and servers. Just like the English language has changed since Shakespeare's time, platforms
and programming languages have changed. Don't get stuck in the past by resisting change.
WAR STORY
It was the early days of J2EE 1.4, and we were to implement the next generation of
banking systems. We had implemented all the best practices, patterns, guidelines,
and anything else we could i nd in topics and online resources.
Our application was heavily dependent on a particular vendor and was not
portable. We had to run the vendor integrated development environment (IDE)
and the vendor server, and this was in the age of 32 bits when Windows refused to
address more than 3GB of RAM. The server and IDE were so slow when started in
debug mode that we did not need breakpoints to stop execution.
The vendor assured us that the production environment was going to be fast;
nevertheless, the development life cycle was like a ball and chain. We could easily
go for coffee breaks while the server restarted.
Things got even more fun when we wanted to go live. The production environment
turned out to be as slow as the development boxes. Soon we all had the habit of
watching prod and test environment's memory statuses.
Finally, we hired a famous consultant to show us what we were doing wrong. He
was an old and wise guy whom we treated like Gandalf. After reviewing our code
for a few days, he asked us to delete almost all façades (we had façades for almost
every bean) and all unnecessary interfaces (again, we almost had interfaces for
interfaces). He also asked us to minimize our lasagna‐like layers by cutting down
the call hierarchy (EJB calling EJB calling EJB…).
It was the J2EE 1.4 days with heavy vendor servers, so nothing magical happened.
Still, we gained some performance and at least achieved much readable code.
Assuming that everything may change, developing with needs for l exibility in mind
does not offer an easier future but most probably a more crippled today.
