Journey of a Craftsman

This year Craftsmen celebrates its 5th birthday, and my (professional) coding career turns 20. Pondering about how time flies I find myself sometimes thinking of the ‘good old days’, like a regular old man 😉

After initially coding on a mainframe I got the opportunity to start coding Java at work around 2004. Thereby narrowly escaping the ‘EJB era’, which doesn’t mean there were no ‘What the …?’-moments left for me to experience anymore. There were lots.

For old times’ sake allow me to share a memory of my first forays into querying a database using Java (1.4 of course).

Plain JDBC query (2004)

Every now and then you encounter people who are convinced all the modern frameworks obscure what is important, and you’re way better off rolling your own because then you ‘know what’s happening’. Well..

…in case you ever feel the urge to write lots of plain ‘and simple’ JDBC queries and related fun, please have a look at this work of art first. Back in the day you would see a lot of this type of code.

Connection conn = ds.getConnection();
try {
   PreparedStatement stmt = Connection.prepareStatement(sql);
   try {
      ResultSet rs = stmt.executeQuery();
      try {
         // do whatever it is you want to do
      } finally {
         try {
            rs.close();
         } catch (SQLException e) {
            log("Cannot close result set", e);
         }
      }
   } finally {
      try {
         stmt.close();
      } catch (SQLException e) {
         log("Cannot close statement", e);
       }
   }
} finally {
   try {
      conn.close();
   } catch (SQLException e) {
      log("Cannot close connection", e);
   }
}

Note that this code only is the required boiler plate code, to be able to do a query, as you can tell by the comment // do whatever it is you want to do . So, after all of this orchestration you would still have to fire an actual handcrafted SQL query ánd map the result to whatever object it is you’re retrieving. Or vice versa in case you’re storing or updating.

It’s rather obvious the sheer amount of code distracts from the issue at hand. Notably in matters of readability, testability and maintainability too. Consider it the first steps into one of those Pandora’s boxes in a legacy code base nobody wants to touch.

By the way, this example actually looks pretty okay, in comparison with other ingenious constructions I have encountered in the past…

As you might know, plain JDBC queries luckily have become easier to manage with the more recent JDK releases, specifically with regards to the given boilerplate example. But you still find yourself writing a lot of code, and if you remove all that boilerplate code, you will still be writing a lot of result set mappings and plain SQL queries. Not to mention having to deal with all the quirks of conversions between DB types and JDK types.

Also note that this is actually still an abstraction of course, so you still don’t know what’s really happening between your code and the data residing in some RDBMS’s files. Anybody ever having used Oracle’s JDBC drivers can probably tell a war story or two about that.

Point being: let’s leave those war stories up to the veterans, shall we?

Standing on the shoulders of giants we have evolved. The solution to modern day problems hardly ever is, to start (completely) from scratch. You’ll be throwing away years of work and experience, and you are most likely to bump into many of the challenges and problems your predecessors faced before you.

Or, as Peter den Haan back in 2004, said:

If you want to write good JDBC code, you’ll write over two dozen lines of clutter to execute one pesky SQL query. Unsurprisingly, almost no-one does this, and virtual all JDBC code suffers from potential resource leaks and/or obscured exceptions. This is why frameworks such as the Spring JDBC template or the higher-level iBatis are IMHO indispensable tools. Never write raw JDBC. It’s just too hard and cumbersome to get right.

Closing tip? Check out this modern day alternative of (my) preference: Spring Data JDBC (examples on GitHub, reference documentation).