People are still writing straight JDBC Code?

In one of my scenario where a product engineer is looking for an app that can take his command sent from his machine through network, and being able to save into database. I used Tomcat with pure JDBC code to do that because Spring and Hibernate frameworks actually give trouble of ORM overheads.

That's what you usually get for using tools that you don't understand / know well enough to use them correctly. As a junionr I saw usages of Hibernate implemented by seniors in such a way that I wanted to cry - there was no understanding of anything, and it was because nobody ever read anything on the topic. Was this ego? Lack of time? I have no idea; what I know is that the code was utter nonsense, which was not fault of the tool, but of the people who used it incorrectly.

As for the auto-generated schema - nobody on the Hibernate team ever said you should use it for production. It is only natural to employ a DBA for 2 straight days / weeks to pimp it up.

That being said, I prefer other tools to Hibernate.

I too have had a terrible experience not only with Hibernate, and with every other ORM out there, when trying to do anything remotely advanced or complex. Most are brain dead and impose naive schemas that are not optimized for anything other than small scale applications. Hibernate doesn't play nicely with transactions at all, it doesn't work reliably with caching causing all kinds of weird errors because of extremely poor cache management. I do agree that writing alot of the boilerplate code is error prone and messy and Java is nothing if not full of boiler plate code. I don't think moving the boilerplate code to Spring is any better, it is just as messy. I created the following project to do the boilerplate for me. http://code.google.com/p/sqlck/ it is moving to GitHub just as soon as I get a chance to update it and move it.

The illusion of Hibernate is that it pretends that you don't have to care about the database to deal with it, which is completely false. At least, with JDBC (and the help of annotated transactions, Sproing JDBC templates and RowMapper), you're aware of what you're doing.

Hibernate or JPA can be great productivity tools, but they have to be used very cautiously, under the supervision of experienced people. As a technical team leader, I'd certainly recommand it neither for a junior team, nor for a big expericeed team.

Depends on the scope of the application and the exact nature of the sql. For complex model and dependency management it is worth the effort to invest in an ORM, but if you have simple table (or several) with simple flows then why to put ORM and its adjoining complexity? In many cases this code also reside in its own project (let's say a war that provides some services) and for me there is no reason to increase its size just for the sake of ORM.

Using Spring and JdbcTemplate (which is what we do), takes almost all the pain if handling connections, statements and all the preparation and clean up which are the main problem of using jdbc.

The reasons why people fail with frameworks are usually always the same: They do not read the documentation well enough and /or lack the theoretical background, then they jump straight to the implementation, usually without automated tests, so they see the wrong results just when they thought they were almost done.

ORMs are complex by nature, and always will be.

Of course, i'd prefer a working application with "plain" JDBC  over a non-working (buggy) application with an ORM, but the cause is not the ORM or any framework as such, but the lack of skills in the development team.

Pick your frameworks wisely, based on evalution and the skill level/experience of the team, not on marketing. The choices made that have lots of consequences are also known to be part of the architecture.

This is not just the case with ORM, but also applies to WebFrameworks, build tools, DI Frameworks, etc. pp.

Some frameworks have their own set of problems, like EJB 2.x and JSF 1.x.

For most green field projects i use an ORM, but using iBatis/MyBatis for brown field projects with an existing schema often has advantages ime.

 

I totally agree with everyone here about not trusting Hibernate. One of my projects was to build middleware for multiple front end. I was using Tomcat with Hibernate and I tried to make it lightweight enough on everything else and so my middleware could survive the non-functional requirements because it was sitting on a 1U Dell Dual Core 2GB. I was believing it that it should have plenty of power to handle all requests because I made all requests from front ends all lightweight.

Yes, it worked. BUT, it crashed.

I thought the story ended when I tested so many times, end-to-end and UAT. Everything went well. But after the weekend, users reported "no response" from front end on Monday. I spent so much time on investigating it and finally I found that it was a Hibernate memory leak issue. Weird, isn't it? The problem was, when there were requests coming continuously, the memory were reused and so server and hibernate were considered active. However, when there were no requests coming in for certain amount of time, the JDBC pool was trying to shrink down to minimum pool size and that triggered the memory unable to release error in Hibernate because it had references to it. It was tracked as major defect in major release of 3.2.4 or something. That was a very bad one!

I agree that having an understanding of the behind the scenes knowledge important and I would advise developers to invest time in this.

However, there are fundamentals in evolution at work here. Would I trust building my application on Spring, written by experts, used by millions in countless applications world wide, or on your proprietary implementation?

Should we always all have knowledge of lower level details? At some point you need to build upon something you don't have full understanding of and can trust. For example what do you know about hardware design? Does it really matter relative to what you know at the higher level?

The abstraction point is very important here. Spring JDBC provides what JDBC does but at a higher abstraction by hiding boiler plate, and therefore should always be favoured. ORM's address different concerns so cannot be taken as a straight form of substitution for JDBC.

I could not agree more with Jilles van Gurp, all of his points are valid and resonate with my experience as well. What is interesting, I have learned Ruby on Rails a few years back, and was thoroughly impressed by ActiveRecord - this is a Ruby ORM for RoR. Experience using it was a refresher after heavy handed frameworks in Java, so much so, that after waiting for some time for someone to implement this in Java, I decided to do this myself. If anyone interested in a truly lightweight Java ORM, you can try ActiveJDBC. I will be publishing an introductory article on DZone soon. Some initial blogs can be found here: http://igorpolevoy.blogspot.com/2010/02/activerecord-in-java-activejdbc.html and here: http://java.productiveedge.com/

 I tried to strike a good balance with the API simplicity, performance of the ORM layer, and especially making it as intuitive as possible. 

enjoy

igor

Hibernate itself isn't bad, as long as you observe some rules as soon as you are working in bigger scenarios:

1. Do not integrate the DAOs directly into upper layers as first-class values. The problem in both scenarios is that the structure of DAOs usually does not match the exact requirements of the usecases in which your are working. Rather write your own Types which match the usecase, and do not try to "hack" the DAOs to match it by a series of if's and elses. There is a large difference between the UI view and the DB structure, which can rarely be translated directly.
2. Never use DAOs as data transfer objects! The worst problem with hibernate-daos is that you can never rely on lazily-loaded values. The type has a getter for a list of relation objects, but who says that these have been read? This was a common source of bugs in my applications.
3. Relations Again: IMHO, OR-Mapping should not map these things directly anyway into the beans. Relation-Fetching can eat up a lot of performance and it is very complex. I prefer beans without relations and manual querying for the relations. Also, as seen in the previous point, it cannot be transparent and then can be source of bugs.