The year isn't long, is it? Time seems to be whipping along at a tremendous pace. It seems like only a couple of weeks ago that we were at JavaOne talking over all things Java with anyone prepared to listen. We spoke to Sun, IBM and Oracle, to name but a few of the big boys. Now, Oracle...well, there's a tale to be told. But first I'd better introduce this column. I got a bit excited there.
For those of you new to this fine journal, let me introduce myself. My name is Alan Williamson, and I write this Straight Talking column, which is now creeping into its second month. So don't worry...you haven't missed much yet; I'm only warming up.
What's the purpose of this column, you ask? What am I supposed to be conveying in this little piece of magazine real estate? Well, here in my world I want to take you behind the marketing hype and give you a real-world view of Java. I'm one of Java's biggest fans, and I stand up for it at every opportunity. I'm not blind or blinkered to its problems, however. Journeying down the Java development road isn't always the blissful trek we are led to believe. Promises of no more pointer crashes may be true, but a host of new problems have been introduced that make chasing a pointer problem seem like an absolute busman's holiday. I intend to highlight some of them, and, I hope, save you time if and when you hit the same circumstances.
Each month I'll take another character attribute and, as a bit of fun, apply it to the world of Java. Last month I looked at trust. This time let's take a peep at faith.
What is faith? Collins' English Dictionary (1993) tells me it's a strong belief, without proof. Sounds like the definition I've been working with for a number of years. As a developer I generally have faith in what bigger companies tell me. For example, although we employ a number of people, my company, N-ARY Limited, is small fry when compared to the corporate giants of, say, Borland (sorry, Inprise!), Symantec, Sun or Oracle. Both Borland (sorry, there I go again, Inprise) and Symantec have been developing compilers and development tools since day one. So to say they know a thing or six about this subject would be an understatement. As Steve Martin uttered in the classic movie The Man with Two Brains: "When a woman who has just had brain surgery says she has a headache, you have to listen." Therefore, if one of these companies offers assistance, since it is coming straight from the horse's mouth, you feel you really ought to follow it.
But every so often even these guys fall over their own arrogance, and here I am referring specifically to Oracle and their attitude toward JDBC, Java's database classes. So this month's public health warning is JDBC drivers.
Before I begin destroying Oracle completely, I want it known that I believe them to have one of the best database engines on the market today, and they really have some cutting-edge technology. Oracle8 is a fine piece of software. However, they don't have a clue about Java. As one of the biggest database companies in the world, their apparent neglect of the Java community is something we should be concerned about. Sure, they openly promote all these new Java add-ons and extensions you can buy from them, but if they can't even code a proper JDBC driver for their own database, then doubt has to be cast on their other Java products.
Let me illustrate this with a problem that has faced around 90% of Java developers who have tried to hook their code into an Oracle database. (I have no way of proving this figure, of course, but if the newsgroups, discussions with third-party driver companies and Oracle themselves are to be believed, then I estimate the percentage to be very high.) Now this problem, sadly, is not unique to Oracle, but at least the other database companies are openly trying to rectify the problem. Oracle doesn't appear to admit, officially, that a problem exists. Nonetheless, they illustrate the power and flexibility of Java with their handling of it.
The JDBC API is a set of classes that allows developers to safely code database applications without having to worry about the specific implementation details of the back-end database. Thus it allows the developer the ability to switch to, say, an Oracle database to replace an MS-Access alternative without having to recompile their source code. A fine piece of technology, assuming you've stuck to standard SQL, that on the whole works extremely well.
The secret to the success of JDBC is the driver. Now this is a piece of software that sits between your application and the database. It's the communication bridge. Its main role in life is to pass SQL queries to the database and then collate the resulting data from the execution. It doesn't sound difficult, but this area is fraught with danger.
JDBC drivers come in four types. Some are written in Pure Java, and may be run on any Java-enabled platform; some are native libraries written for a specific platform. The driver type gives an indication of the amount of native code employed. For example, types 3 and 4 drivers are generally Pure Java solutions. Choosing the driver is an important part of the development cycle. A badly chosen driver will be slow and in some instances may crash; a good driver will be fast and efficient, and will outlive the life of your application.
Drivers that employ native libraries generally have a higher chance of crashing than drivers that are implemented in Pure Java. Therefore, the tendency to favor type 3 and 4 drivers is never a bad thing.
So...back to our story. We had been implementing a major server-side application employing over 80 servlets, all accessing an Oracle database. For the sake of convenience, all of our developers installed a local Oracle server on their NT boxes, which is used to develop and test. Early on, warning bells began to ring. There were reports of Java hanging, and General Protection Faults were observed on a daily basis. Dr. Watson became a friend to us all. Our database expert had spoken to Oracle and they assured us it was the JDBC driver, but have no fear, Oracle8 will take you on the road to recovery. Hooray, we thought. We had Oracle8, and a brand spanking new Sun Solaris box to run it on which was due to arrive any day, so we lived with the problems.
In the meantime, JavaOne popped up, so our database expert and I went over there. We knew we had problems with Oracle, and we knew we weren't alone: whenever we used either of Oracle's JDBC drivers, we got GPFs after a short time of use. At this stage of the game we had committed to Oracle and couldn't really change our back end. But we were very worried about the stability. We had heard of third-party JDBC drivers, but thought, well, if Oracle can't even keep theirs up long enough, then the outside companies probably won't have any better luck.
We echoed this concern to one of the senior Oracle developers at JavaOne. He assured us that although the version of Oracle we were using, 7.3.3, had problems, Oracle8 should address them. He seemed to know about the problem and was very confident in his advice, so we were as well. We had reassurance from Oracle. We had faith that Oracle, being the size they are and dominating the database market, wouldn't let a problem like this sit for long.
We flew home, happier. Eventually, Oracle8 and the new server arrived. We eagerly installed both, and spent about two days configuring the back-end database engine to all our tables and ensuring it was running as efficiently as it could. We also installed the JDBC drivers straight off the CD-ROM. We then copied our Java packages onto Solaris and ran the test server up.
You know the feeling you get when you open a present expecting it to be the one item you've had your heart set on for weeks? And the letdown you have when you discover something else? Well, we had the same feeling.
We ran our tests for all of two minutes. This was as long as the driver stayed up. We couldn't believe it. Devastated didn't come close to what we were feeling. What were we going to do? I rang up Oracle and asked for support. They said, "Sorry, you didn't buy any." I told them, "Excuse me, but I am not paying for me to tell you about your problems. If it's something we've done wrong, then I will pay for support, but otherwise, no." Alas, the telephone support didn't see it quite like this and hung up. Charming. Now what?
Well, the power of the Internet came into play. I looked around and discovered a lot of people who had the exact same problem. I even found one chap who had collated Dr. Watson logs, Java dumps, code snippets and repeatability tests, and he got nowhere with Oracle. He did, however, point me in the direction of a San Francisco-based Java company known as WebLogic. I e-mailed them and told them my problem. They e-mailed back - within 15 minutes, I have to say - and told me not to worry, they had heard our problem a thousand times, to try this driver and it will fix our problem. I felt like a dying man who had just met a set of doctors who could cure me. It was wonderful.
I downloaded the 30-day trial, installed it within six minutes and fired up our application. Believe it or not, it is still running after two months of continual use. We didn't have to touch a single line of our code, nor did we have to change any tables. It worked, and worked well.
But the Oracle driver wouldn't work for love or money. We told Oracle, and they refused to talk to us unless we bought support. Brilliant. Here we had spent all this money on Oracle8 licenses, and when it came to the crunch, the whole system wasn't working due to a small JDBC driver. When we swapped in a third-party JDBC driver, it worked.
WebLogic was fantastic, and after talking with them for a while I discovered that the Oracle driver is one of their best product lines. No wonder. They sympathized with us and told us many others had also faced this apparent lack of support from Oracle.
The moral of the tale is that blind faith is very dangerous to have. Java is much more than simply coding classes; it's the deployment that can make or break the end application. And if it's a database-dependent application, the whole system can pivot around one small piece of software that isn't even in your control. Choose your JDBC driver very carefully, and don't stick to the one shipped as standard with your database. You could waste a lot of time.
Sadly, we have joined the mass of Java developers who no longer have faith in Oracle. I think Oracle needs to take a leaf out of Sun's book with regard to how they treat developers. Once they get over this stupid support policy they have, maybe we can all work together and produce a complete package that works from end to end. I was reminded by a colleague that if Oracle were Microsoft, Mr. Gates would probably have bought WebLogic and deployed it as his own. This would definitely be a solution, as at the end of the day what all developers want is a system that works, something they can have faith in.
About the Author
Alan Williamson is on the board of directors at
N-ARY Limited, a UK-based Java software company specializing solely in JDBC and Java servlets. He recently completed his second book, focusing purely on Java servlets. In his first book he looked at using Java/JDBC/servlets to provide an efficient database solution. You can e-mail him at email@example.com