The reasons that should convince me to abandon EJB+JDBC have many precondidions. Those pre-conds are not true in our organization. Let me clarify:

1. JDBC is tedious to write
No it isn't. Most of the code is in AbstractDAO class, including loading parameters to fetch the connection, fetching the connection and closing all the things that need to be closed. Every SQL stored procedure call from Java looks exactly same in the Java code and errors are very easy to spot there.

2. Increased development time
Maybe. I don't know where that increase comes from, since writing the DAO class (SQL procedure call) is very quick.

3. SQL is only as good as the developer who wrote it
Yes. And it actually is great. Our Java-developers don't write SQL. Database specialists write it and Java code simply calls procedures. Actually, everything else except calling stored procedures is strictly forbidden. Those same stored procedures are often called by several separate applications, even from different platforms.

In my opinion and our few year experience, this all seems to result in superior efficiency compared to using Hibernate or other O/R mapping tools. A few times some projects have tried Hibernate, Entity Beans and iBatis for example. The results have been a total catastrophe, according to both efficiency and maintainability of the code.

4. SQL code not portable
So what? Our database is the same as it's always been and the code will never be run outside of our organization. Secondly, by checking the actual code it can be seen that most of it actually does not use any vendor specific features, and is portable.

5. Increased maintenance and support
I don't get this. Who needs to be supported? In my opinion, JDBC is simpler to write than O/R mapping tools or AOP/POJO frameworks. And with JDBC, you dont need any cryptic configuration files. Simply switching on container-managed transactions for the EJB and telling the DAO which connection pool is to be used is the configuration you need to do.
I would say that JDBC with stored procedures leads to decreased maintenance instead. You can change the database and the stored procedures as long as the procedure interface doesnt change. The Java code need not be changed.

Featured White Papers