Java J2EE Portal
Enterprise Java Station
J2EE curve
Java News / Articles
Java News / Articles
Java Open Source VoIP Platform - JAIN SLEE
JEE
Grid Enabling Data Intensive JEE applications
A quick look at EJB 3.0 Stateless Session Beans
Processing...
Buy Java, Deals On Software Technology Store
Click here for great deals on computers, laptops, software and books
With improved JDBC 4.0, do we still need fancy persistence and relational mapping technologies? PDF Print
Written by Content Team   
Aug 07, 2006 at 01:51 AM

Java SE 6.0 is expected to be released in October 06. An important part of the new version of Java is the new JDBC 4.0 API. JDBC 4.0 brings several changes to JDBC, but its top priority is making things easier for developers.


Looking at the new features, one wonders if its time to go back to plain old JDBC?
Too much boilerplate code and disconnect from object oriented development were amongst the top reasons why developers moved from JDBC to ORM technologies like Hibernate. With version 4.0, JDBC is making a comeback.

Interesting developments in JDBC 4.0 are:

  1. No need to explicitly load JDBC drivers using Class.forName() to register a JDBC driver. The DriverManager class takes care of this automatically.
  2. Java SE Service Provider mechanism as another means to specify database drivers
  3. Specify SQL queries using Annotations
  4. Bundled database based on Apache Derby
  5. SQL 2003 support, including support for XML as a native database data type
  6. Improved exception handling with new exception classes
  7. A new DataSet interface. When used in a connected mode, the DataSet functions in a manner similar to ResultSet. A disconnected DataSet functions in a manner similar to a CachedRowSet. You can navigate, modify and delete records in a DataSet.
These new features and the fact that almost all Java developers know JDBC, JDBC does again look like a promising alternative.

Also irrespective of developments in persistence technologies and the emergence of several new APIs like JPA, EJB 3.0, standards and tools, many Java developers still feel that JDBC is the simplest and fastest way to work with databases. So there's a readymade following for JDBC that won't hesitate to go back to it.

Also considering recent trends to reduce complexity in Java development, JDBC should fit in well.

Frank Sommers in his article "Upcoming Features in JDBC 4" says "introducing O/R mapping into an application just to make it easier to work with relational databases incurs additional complexity that could be avoided by an improved JDBC API. " . Srini Penchikala in his article JDBC 4.0 Enhancements in Java SE 6 says "The main objectives of the new JDBC features are to provide a simpler design and better developer experience."

So have we come full circle? Is it time to go back to good old JDBC? Do share your comments below.

Related
>> How to decide which persistence technology to use? JDBC / CMP Entity Beans / Hibernate / JDO?
>> Quick Hibernate - Tutorial
>> New MS JDBC Driver for SQL Server 2005 - JAVA J2EE PORTAL
>> Oracle releases free database
>> GOF Factory - Have your own too
>> Hibernate 3.0 is the world's most sophisticated (ORXM) solution ...
>> Checking EJB 3.0 performance


User Comments

Comment by 'Guest' on 2006-08-07 04:13:24
The new kids driven by hype around ORM products like Hibernate tried them. The old Java developers were always using JDBC.  
 
JDBC 4.0 is good news. Although a simplification of the exception handling mechanism would have been great. 
 

Comment by 'Guest' on 2006-08-07 10:32:57
Why not use Object relational mapping tools if it is obviously simpler than using any version of JDBC ?

Comment by 'Guest' on 2006-08-10 00:26:21
I think there is two big categories of application in the real world:  
- "entity-based" application 
You define a clear set of entities for your application and use them for all 
your operation 
- "data-centric" application 
you split you code in one logic layer and one data access layer, but  
your data access layer manipulate the tables directly, not alway passing through an entity representation. 
 
My opinion is that "data-centric" is actually the way most application are coded. 
 
As an example consider the typical sceniario below: 
You have customer and order tables and you need to display in a grid each customer and its # of orders. 
 
- in "entity-based" application you simply load all the customers.  
They will have a property with the list of orders. What you need populate the grid  
by iterating over the list of customers and getting the size of the order list for each customer. 
 
- in "data-centric" application, most of the time, you will have a query in your access layer 
such as "select c.name, count(o) from customer c inner join order o on c.id = o.customer_id group by c.name" 
The result of this query can not be mapped to an entity, if you want to use the result you will need do one of the following: 
- bind the ResultSet to the grid 
- load the ResultSet into some disconnected structure for later usage (DataSet, XML, or other structure) 
 
Both solution can lead to clean, well-defined application. It all depends on your needs.  
 
In "data-centric" application, it is often hard to know what are the data structure that are passed across the tiers (Array for "single column select", XML, DataSet, Custom classes) because they may vary. 
In "entity-based" application, other problems may appear: performance, partial entity loading, complex database structure... 
 
My final word will be about database independance: JDBC provides some database independent syntax ("escape syntax") 
that is very usefull. If you want to achieve database independent (or less dependent) solution consider this + some custom code in your data access layer  
before immediately chosing an OR mapping tool. 
Your Name / Email Address
Comment
Spam Protection - Please enter the code in the image -

Listen to code


Add This Feed Button

Enter your Email


Java Expert Interviews
MarkSchiefelbein-BackbaseAjaxFramework
All Ajax development can happen serverside using the Backbase framework and JSF
Ramesh Loganathan Pramati
Pramati 4.1 and beyond: An interview with Ramesh Loganathan
TonyMorrisJTiger
Why pick JTiger Java Unit Testing Framework over good old JUnit?
Processing...
Go to top of page  Home |
SiteMap

Copyright 2004 to 2008 Rightrix Solutions. All rights reserved. All product names are trademarks of their respective companies. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Rightrix Solutions and IndicThreads.com are independent of Sun Microsystems, Inc.

Views expressed at IndicThreads.com reflect the views of the authors alone, and do not necessarily reflect those of IndicThreads.com. IndicThreads.com and it's authors are not responsible for reader comments and opinions.

Enterprise Java J2EE JEE Portal >> IndicThreads.com