One of the objectives of Hibernate and other ORM tools is to abstract the persistence of an object. Hibernate works hard to provide as much flexibility as JDBC offers while at the same time removing much of the maintenance headaches that are associated with managing SQL statements embedded into an application.
There are some additional considerations and complexity that must be tackled, but this quickly becomes a non-issue as a developer becomes adept with the framework. The complexities that were ones a problem with JDBC (connection management, connection pooling, caching, lazy-loading associations, etc.) become configuration driven and no longer an issue for a developer to contend with.
With HQL (Hibernate Query Language) the developer can achieve nearly all of the same semantics that are available in SQL. All the power of the relational database is still present and can even be reinforced in the application through column definition, foreign keys, etc. on the object meta-data (which is amazingly simple with annotations).
If you additionally leverage Spring in conjunction with Hibernate (or JPA) you will also reap the benefit of springs transaction management, connection management, etc. and still have access to the underlying JDBC connection if you find a reason to need it.
A veces es mejor usar JDBC directamente en una query compleja, Hibernate nos soluciona el mapeo de nuestros objetos, pero en caso de querys de recuperacion de datos particulares, que por ahi no estan mapeados a objetos, o incluso objetos pero tales que el mapping no nos ayuda a obtener lo que queremos (caso JBPM_VARIABLEINSTANCE, Hibernate 3.5) conviene obtener el dato con JDBC, no perdamos de vista que Hibernate USA Jdbc
http://forum.springsource.org/archive/index.php/t-10359.html
