In the beginning there was nothing: no Java and no data.

Then someone said, let there be data and relational databases with SQL were born.

And someone said, let Java talk to databases, and JDBC was born.

And someone saw that JDBC was good, but someone else saw that JDBC was bad, and EJB with CMP were created.

And someone said, J2EE containers are bad and POJO has resurrected.

And entity beans were slow and heavy; Hibernate was born and people forgot SQL, which was a sin.

And someone said, J2EE is no good, and he divided Spring framework from J2EE.

And fifty more people said nothing is good, and they created fifty more Java frameworks. And poor Java Joe said, "I'm sick and tired of this variety. I'm going back to Java EE."

Some enterprise Java shops that were using J2EE application servers and EJB 2.x found that the combination was overkill for most of their applications, and decided to look for an alternative. Spring framework combined with Hibernate seems to be a logical alternative to J2EE, but will this combo deliver a light weight replacement for Java EE, especially when greatly simplified EJB 3.0 is available?

In my opinion, not only the Spring/Hibernate combo, but even each one separately, is pretty heavy as any framework. Only reusable loosely coupled components are lightweights.

Spring framework is presented as a set of components that can be used separately, but you can also wire them together by adding two pounds of XML. But the minute you do this, you fall into an XML trap. If you use any single component of the Spring framework, it's lightweight. But since it takes two to tango, it's as if you're pulling a tiny roll of thin wire out of your pocket (a.k.a. XML), which becomes heavyweight because wires tend to twist and create a mess.

Concerning Hibernate, I'm not even sure why so many people are using it in the first place. I could see an enterprise architect wanting to use it to lay out a brand new design of a stack of business applications, and to enforce it to a firm-wide standard for data persistence. But if you're developing a typical CRUD application, especially when it comes to using already existing and not perfectly designed databases, why even bother with Hibernate? Does SQL scare you that much?

Take an application built on Spring components interconnected with thin wires, put Hibernate on top of it with wires of a different diameter, and the maintainability of your application will decrease while hard- to-find bugs make themselves at home in your application.

Over the last three to four years, many people have been bashing EJBs as an unnecessary complicated framework with lots of convoluted XML descriptors. Now EJB 3.0, with its annotations, is trying to appeal to enterprise developers again. This won't be easy, because bad memories last for years. But don't kid yourself when you substitute EJB for the Spring/Hibernate combo: it won't make your life much easier.

I do believe in standalone POJOs that know nothing about the environment they're in, but do know how to perform a specific function (i.e., send a message, manage transactions, create a pretty report based on provided SQL, model some financial process, find an optimal route, and the like). Just pass the required parameters to this black box, get the result back, and do whatever you want with it. Inversion of Control or the Dependency Injection paradigm is nothing new, and it works fine. For ten years, I've been routinely using it (without knowing its future name) in my PowerBuilder applications. It was a period of event-driven programming. We were creating user objects with custom events. Whoever wanted to pass some information to this object would fire a custom event that would carry required data and inject them right into the object. Look, ma! No wires! Today, I do the same thing in ActionScript 3. Stop wiring, just write the code required by your business application and forget about it when the new project starts. But don't forget about independent reusable components.

Spring is probably one of the best Java frameworks available today. It has only one drawback: it's a framework.

Hibernate offers you a caching object? Great! Let's use it, without the need to install the whole shebang. Get the caching component somewhere, roll up your sleeves, and create an instance of this object passing all required parameters to its constructor. Stop wiring; get back to programming. The combination of good knowledge of SQL, JDBC, caching (only if needed), and a pagination component (only if needed) can get you pretty far.

At one of my recent presentations to Java developers, I asked the question, "Who knows how to delete duplicates from a database table?" No one knew. When I asked the same question on one of the online forums, some Java developer proudly announced that with Hibernate, you don't create duplicates in the first place. Thank you very much! How about some real world experience? What if the database table with dirty data already exists and dirty feeds keep coming in nightly? Do not kid yourself. Learn SQL.

If you want to write a simple application, don't start by looking for a "light-weight" third or fourth party framework. Program your business logic in POJOs, and your database access in DAOs. Keep it simple. Need transactions? Find a transaction manager. Need scalability? Consider using asynchronous messaging between components.

Floyd Marinescu starts his foreword to the book "Beginning EJB 3" (aPress) as follows:

EJB 3 is a very important milestone for the specification. Not only is it significantly easier to use, but also for the first time (in my opinion), the specification is now built around the proven needs of the development community, standardizing existing best practices instead of being the result of design by committee.

It's great that the bad guys from some evil committee were finally overthrown by the good guys, who are actually paying attention and incorporating best practices and ideas of the multitude of open source frameworks.

And someone said, go back to Java EE standards. And he created Java EE 1.5 and it was good. It was not the best, but it gave people a common ground and fertile soil for seeds of a new generation of enterprise Java applications.
Amen.