Welcome!

Java Authors: Lori MacVittie, Yeshim Deniz, Mike Kavis, Elizabeth White, Liz McMillan

Related Topics: Java

Java: Article

Spring + Hibernate EJB3, POJO + JDBC?

All Hail, The Return To Java EE Standards!

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.

More Stories By Yakov Fain

Yakov Fain is a co-founder of two software companies: Farata Systems and SuranceBay. He authored several technical books and lots of articles on software development. Yakov is Java Champion (https://java-champions.java.net). He leads leads Princeton Java Users Group. Two of Yakov's books will go in print this year: "Enterprise Web Development" (O'Reilly) and "Java For Kids" (No Starch Press).

Comments (14) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Jurgen Van Oosterwijck Blogs 11/29/06 08:42:51 PM EST

Trackback Added: Frameworks vs JEE standards; Yakov Fain writes about the clash between POJO frameworks and standardized JEE.
As far as I see it, the new JEE5 standards are a way of getting back some of the marketshare.
Marketshare that was taken by Spring on one hand as the EJB alternative

Yakov 11/23/06 07:18:39 PM EST

I do not have negative attitude toward Spring - it's one of the best Java frameworks available today. But I do not see it as a revolutionary framework, just different. I do not think that it's a lot easier than J2EE when it comes to real world projects.
Today's enterprise Java programming is overly complicated, which make projects more expensive to develop than they need to be.

Justin 11/22/06 10:39:30 PM EST

I don't like the negative attitude you seem to hold about Spring. Spring came along at a time when EJB was a complete and utter mess. Some really bright people realized that and created something lightweight and extensible. Spring XML and wiring beans is a joy in comparison, and really is a no brainer. In my book, Spring + Hibernate have already proven themselves. EJB3 better be pretty damn good to remove that oh so bitter taste that 1 and 2 left behind...

Yi 11/21/06 05:56:37 PM EST

I use hibernate and I'm not scared of sql. For CRUD apps, it can be tedious to use jdbc because you end up binding your java variables to the db fields 3 times (for insert, update and select) in the jdbc code, while with hibernate you just do it once. The difference can be quite significant if you have a lot of db columns.

jeff davidson 11/19/06 01:37:43 PM EST

delete
from
emp e
where
rowid > (select min(rowid) from emp e2
where e.id = e2.id);

Agusti Pons 11/17/06 11:18:55 AM EST

Very goog article.

For years I've been developing my own framework to interact with backend systems (say databases).

The work is public in http://www.microcalls.org

It may be interesting to you.

Thank you

{Complexity} 11/16/06 07:43:17 PM EST

Trackback Added: he Return To Java EE Standards!; He didn’t mention why EJB3.0 is better than other framework though, it’s quite meaningful in terms of unification. That’s true there are too many frameworks out there!!
Spring + Hibernate EJB3, POJO + JDBC?
— In the beginning there was ...

Rob Bygrave 11/16/06 06:47:25 PM EST

Great article but perhaps I don't 100% agree.

- SQL Knowledge is important - Totally
- JDBC Knowledge is important - Totally
- Simplicity is important - Totally
- Spring/Hibernate approximates EJB3 in complexity - Totally
- We should just write JDBC - not so sure...

For me I'd look to EJB3, JDBC and what is in the middle ground.

1. Is EJB3 more complex than it needs to be?
2. Is writing raw JDBC really a good option?
3. Is there middle ground?

Is EJB3 more complex than it needs to be?
-----------------------------------------
From my perspective EJB3 has inherited unnecessary complexity from Hibernate and Toplink.

The EntityManager, attached/detached beans, merge, flush are all inherited concepts that are not actually necessary for ORM.

Ebean offers EJB3 ORM features for about 800k and I think other frameworks will come that provide EJB3 features with a much simpler API.

Refer: http://www.avaje.org/ejb3.html

Is writing raw JDBC really a better option?
-------------------------------------------
Don't get me wrong - in pretty much any real world app there may be a need for raw JDBC.

With a different slant I would say that ORM is good, but that relational approaches are sometimes simpler and easier. For me this is the case for updates/deletes in a stateless environment
and for Ad Hoc queries (I don't think ORM is well suited to these cases).

However,once you start caching something you also need to understand how to invalidate the cache and how this works in a clustered environment.

- Then you decide you want Statement Batching...
- Then you decide to support Oracle, MySql and SQL Server and find the inserts work a little differently
- Then you want to use LIMIT, or ROW_NUMBER to perform pagination on the database side
- Then you decide you want event listening
- Then you decide to integrate Lucene Text Searching...

Now perhaps this doesn't happen but I would suggest that once you start down the road of writing JDBC for everything then maybe you end up with something that starts looking like a lightweight persistence framework?

Is there middle ground?
-----------------------
Obviously I am biased as I wrote Ebean exactly to fit into this middle ground for people who want EJB3 (or Spring/Hibernate) features but are put off by the complexity.

More than that, there are some interesting omissions from the EJB3 API. http://www.avaje.org/ejb3api.html

However I would expect other projects to be out there to do exactly the same thing. These simpler ORM products may be a better option for some.

scott m gardner 11/16/06 05:27:15 PM EST

Why use Spring, you ask? I use it so that I can develop and test my code independently, so that beans do not need to know the other beans and to reduce fragility. The minimal amount of XML required to wire beans together is a vast improvement and simplification of the reams interdependent code and factories required with out. The only part of Spring that could possibly be considered heavy weight is the database templating, and I don't use that. To consider the Spring core heavy weight might suggest that the lifter is a light-weight ;)

The only reason not to use Hibernate when doing OO programing is that you are stuck using DB2400 and its broken JDBC implementation. Although Hibernate has a defininte learning curve and requires a skilled domain modeller to take full advantage of it, it is still one of the best ways to keep the business logic in the object model and insulate your project from the relation model.

Alain Bergeron 11/16/06 01:26:55 PM EST

If I may, hibernate and any pojo like ORM tools are great when you have a skilled OO team. Otherwise, you still end up mapping your jdbc result set to java object and by mean of reuse, you will end up creating your own little home made framework which the support team or other developers will have to learn instead of a well known frmework like hibernate. That said, I am currenly using ejb3 and so far looks very good either for a small team or a bigger team.

BigBadJim 11/16/06 10:00:44 AM EST

You nailed it! I'm forwarding this to all my fawning acolytes at work!

Shamsher Dhaka 11/16/06 06:54:13 AM EST

Hi,
I truly ackn of what you said in this article. Keep the base and concept strong over which the frameworks are layed.

regards,
Shamsher

Paul Sager 11/16/06 12:16:40 AM EST

Many stars **** for you thoughts, confirming my deeper feelings about heavy weight frameworks. I am stuck in a medium-sized application, consisting simply of many small processes, which is permanently ensnared in an obsolete version of a major AppServer.
Besides being a Java developer, as a Christian pastor, I take the Biblical allusion as a non-offensive creative rhetorical style, handled artistically; as I hope you intended it.

Antonio W. Lagnda 11/15/06 07:24:36 PM EST

Entertaining article.

Spring + iBatis or Spring + Spring JdbcTemplate will give you SQL experience as well.