Lance Andersen's Blog

JDBC EoD API Deferred

Based on our analysis, we would not be able to stabilize the JDBC EoD RI without slipping the Java SE 6 schedule by at least 8 weeks, which is something that none of us want.

The JDBC 4.0 Expert Group agrees that we should not delay Java SE 6 for this feature and as of build 101 of Java SE 6, the JDBC EoD RI has been removed.

I do believe that the proposed features in the JDBC EoD API are useful and we will work toward including an improved version of the API in Java SE 7.

Comments

• Are you talking about the API or the RI?
  

  Posted by: mernst on October 05, 2006 at 10:14 AM

• Both have been removed from SE 6

  Posted by: lancea on October 05, 2006 at 10:20 AM

• Looking at TS-3280, pretty much everything in JDBC 4.0 was labelled as "Ease of Development", which I'm assuming is what you mean by EoD.
  So, what will actually remain, what will go?
  For example, the extra BLOB and CLOB features are really handy, although the object persistence and the automatic driver registration features seem less critical.
  Thanks in advance for clarifying!
  - Chris

  Posted by: chris_e_brown on October 06, 2006 at 01:06 AM

• I was expecting this, because I found a couple of problems with DataSets myself. Also the SQL parsing for ?1 parameters was buggy.

  Posted by: fuerte2 on October 06, 2006 at 05:27 AM

• The feature that is being removed, is what is defined in Chapter 19, Ease of Development. This is the DataSet and associated Annotations such as Select and Update.

  
  All other features are on schedule as planned as as the LOB enhancements.

  Regards
  Lance

  Posted by: lancea on October 06, 2006 at 06:50 AM

• Personally, I had limited interest in the Query/DataSet class, but I had hoped to see my two pet peeves addressed: Eliminating Class.forName and standard exception chaining.

  Posted by: cayhorstmann on October 06, 2006 at 06:51 AM

• Your pet peeves, Auto Discovery of java.sql.Drivers and standard exception chaining are still included in JDBC 4.0

  Posted by: lancea on October 06, 2006 at 06:54 AM

• You took away the single most important reason why I would have loved to upgrade to java 6. I guess I will have to stick to 1.4 at my day job and wait for a java replacement to show up. When you guys came with java 5 , most programmers in my company had little incentive to learn it. Reason websphere did not support 1.5 up until few months ago. Even if websphere supported it, 2 big features were generics and annotations. Most of the programmers had learned to live without generics. and sun did not added any annotation applications which would convince people that its worth learning. So instead of spending time on java, a lot of people in my company spent time learning spring. And now spring is one of the key technology for for our new development. I was very happy that sun added two application for annotations (in jdbc and web services) as part of java se. Now u have removed the annotations for jdbc which would have appealed to maximum number of developers. Number of people writing JDBC is lot more than people writing web services in the enterprise apps. It should come as no surprise that a lot of java developers will not migrate to java 6.

  Posted by: nakuja on October 06, 2006 at 09:50 AM

• 
  Hi Lance,

  
  Even though it is understandable the exclusion of the JDBC EoD API, it is kind of sad for me. I was pretty excited about the DataSet and Annotation stuff. Anyway, are you guys planning to release the JDBC EoD API as a separate download (as the API improves) or do we have to wait for Java SE 7?

  
  Thanks in advance,

  
  Alex.
  

  Posted by: alruiz15 on October 06, 2006 at 11:41 AM

• Hi Alex,

  Thanks for the feedback. It might be possible to release the API to get feedback sooner then Java SE 7.

  Are there specific things that you liked in the current API or would like to see in an improved version if possible?

  -lance

  Posted by: lancea on October 06, 2006 at 11:47 AM

• My JOKE :)
  the EoD is removed bcuz it is too similize to Java Persistence API
  :)

  Posted by: fcmmok on October 06, 2006 at 01:49 PM

• nakuja, check out JPA (= EJB3 entities). That might make annotations worth learning. It's not the right solution for everything, and it is obviously at a higher level than the JDBC annotations. But it saves a huge amount of drudgery, and you can put it to work even if you aren't interested in the rest of EJB.

  Posted by: cayhorstmann on October 06, 2006 at 01:54 PM

• 
  Hi Lance,

  
  Thank very much for you for your reply. I only have been playing with DataSets using toy examples. I apologize in advance if my question does not make sense. Let's assume we have these simple classes:

  public class EmailAccount {
  public String accountName;
  public Email email;
  // some behavior here
  }

  and

  public class Email {
  public String address;
  // some behavior here
  }

  I would like to do something like this in one of my query interfaces:

  @Select("SELECT ACCOUNT_NAME accountName, EMAIL_ADDRESS email.address FROM EMAIL_ACCOUNTS")

  AFAIK, only mapping of simple fields is supported. I would like to see mapping of more complex properties (a la iBATIS).

  Do you think it makes sense?
  Thank you in advance,
  Alex

  Posted by: alruiz15 on October 10, 2006 at 10:56 PM

• Alex,
  Thanks for the suggestion. The original intent of the API was to keep it similar to a ResultSet so there is a 1-1 mapping of the returned results to the DataSet. Your suggestion i think starts to move more towards an ORM which is where the Java Persistence API would come into play.

  The DataSet supported simple fields and Java Bean style property accessors.

  Regards
  Lance

  Posted by: lancea on October 11, 2006 at 10:50 AM

• 
  Hi Lance,

  
  The example I used in my previous comment is still property mapping from the result of a SQL query. IMHO ORM is more than just adding one level of depth in the mapping. Is there any chance that this use case can be considered in JDBC 4.0 EoD?

  
  Thanks,

  
  Alex.
  

  Posted by: alruiz15 on October 11, 2006 at 07:29 PM

• Hi Alex,

  Unless i am misunderstanding your example, you are asking for a totally different intent. The results returned from a query are assigned to a single DataSet object. What i believe you are asking for is the ability to map the returned results to multiple DataSet objects. This was not intended as part of the original design. The intent was to have results map like they are in a Rowset or ResultSet where you have 1 object returned.

  
  Now, i am not saying that this could not be looked at when we review the API, i am just trying to explain the original intent.

  Thank you for your feedback

  Lance

  Posted by: lancea on October 12, 2006 at 07:27 AM

• 
  Hi Lance,

  
  Sorry for the misunderstanding. I should have added this line to the example:

  @Select("SELECT ACCOUNT_NAME accountName, EMAIL_ADDRESS email.address FROM EMAIL_ACCOUNTS")
  DataSet allEmailAccounts();

  And the table in the db has the columns ACCOUNT_NAME and EMAIL_ADDRESS (both VARCHAR). The mapping still involves one DataSet object. When mapping the value from EMAIL_ADDRESS, a new Email object will be created with that value and then assigned to a new EmailAccount.

  
  Thanks,

  Alex

  Posted by: alruiz15 on October 12, 2006 at 10:13 AM

• Data type for DataSet didn't show up:

  @Select("SELECT ACCOUNT_NAME accountName, EMAIL_ADDRESS email.address FROM EMAIL_ACCOUNTS")
  DataSet<EmailAccount> allEmailAccounts();
  

  Posted by: alruiz15 on October 12, 2006 at 10:14 AM

• It's disappointing, but it won't stop me from using 6.0 ASAP. How does this affect anyone who wants to use toplink-essentials.jar and the annotations (for both applications and web-applications)?

  Excuse me if that should be obvious to me.

  Posted by: mike__rainville on October 13, 2006 at 12:54 PM

• Thanks Alex. I will see what we can do in the next version of the API. What you are asking for is something that we had not planned to provide but might be worth re-visiting.

  Posted by: lancea on October 13, 2006 at 01:13 PM

• The removal the the JDBC EoD API has *nothing* to do with the Java Persistence API, so you can use the toplink-essetinals.jar with no issues.

  Regards

  Lance

  Posted by: lancea on October 13, 2006 at 01:14 PM

• 
  Thanks Lance! :)
  

  Posted by: alruiz15 on October 16, 2006 at 10:37 AM

• Why is it necessary to wait until JSE 7 to release JDBC 4.0 EoD enhancements? If it was that close, why not release when it's ready?
  Bill

  Posted by: billfly on February 12, 2007 at 11:05 AM

• 
  I unfortunately (maybe stupidly) was already using the EoD RI for some projects, when I found it missing from the Java 6 release, I started my own OSS project EoD SQL that clones almost all of the features, and adds quite a few extra that I found lacking in the original RI (like rubber-stamping, and simple return types (Lists, Sets, Arrays, etc.)).

  I look forward to seeing how the EoD RI has evolved when it's released in Java 7 :)
  

  Posted by: lemnik on March 10, 2007 at 02:55 AM

• Nice...
  http://www.impact-fellowship.org/_cusudi/0000007a.htm
  http://www.chaco.gov.ar/meccyt/subsecyt/_act1/0000060b.htm
  http://www.chaco.gov.ar/meccyt/subsecyt/_act1/00000353.htm
  http://www.wapug.org.uk/_CoP_discussion/00001ca9.htm
  Harvard - Harvard

  http://www.wapug.org.uk/_CoP_discussion/00001ca8.htm
  Stanford - Stanford
  http://washington.uwc.edu/about/faculty/rybak_c/webpage/_disc10/00005663.htm
  http://orgs.salisbury.edu/fishing/Discussion/0000737f.htm
  Yale - Yale

  Posted by: jamesdalton on January 21, 2008 at 12:32 AM

This work is licensed under a Creative Commons License.