NullPointerException, probably…

Coding to a Bug

leave a comment »

Well, the story goes like this.
Once you have a closed source application to extend (well, you decomiple it of course, but it doesn’t make it open source, do it?). And it is damn old (like 2001 or something, did people actually code then?). And it uses some weird database like MS SQL Server, and, of course a JDBC driver for it, jTDS. Back then, in 2001 version 1.0 of the jTDS was available. It was a little very buggy, for example, putting the driver’s jar in WEB-INF/libs generates NPE, so it have to live in Tomcat’s share lib.
And of course, as any respectable company the vendor of the application developed it’s own wrapper arround JDBC with DatabaseUtilities.getConnection, releaseConnection, and so on.

Now, to the story.
On the surface it looked easy. We obtain connection, bla-bla, executeQuery, ResultSet.hasNext, etc. Works like a charm on clearly installed application. Once they populate the database with their home-made utility for migration from excel… boom. Thier code works, our throws IOEXception – “system cannot find the path specified”. The root of the exception somewhere inside the driver. Google suggests to update the driver to the last version. No prob! Done. Of course I move it from Tomcat’s share to the application lib on that occasion.
Guess what? Our code works like charm, but all other updates in application start failing on it can’t manually commit when auto-commit is on! As I understood it, they just didn’t turn auto-commit off, and the old buggy driver forgave them!

What can you do? The old driver stops working on durty database, the new driver won’t work with their application code. You can’t change the source of their driver wrapper to turn the auto-commit off, because it is closed-source, and you can’t be sure decompiler did a perfect work (and usually it don’t).

Anyway, we rolled-back the driver version, returned it to Tomcat’s shared lib, and went to their JDBC wrapper to look which shaman ceremonies they perform to make it work. We’d better not. They cast the driver to the actual jTDS class and call all kind of implementation methods. I am thankful to them they wrapped all those inside their JDBC wrapper, so all we needed to do is to replace JDBC code with some really strange calls like getQueryResults, which gets the SQL string (not parametrized, of course), and returns array of strings (contatining all the data, including dates and numbers).

So, what do you say? Any better way to do it except coding to the bug?

Written by JBaruch

01/06/2007 at 15:23

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: