Come, friends, family and passersby, welcome to the start of a new column, from the good old keyboard of Alan Williamson. Some of you may have read my previous column under the banner name of 'Visual Cafe.' That column looked at various aspects of the Java language, including such goodies as POP and SMTP. This column is going to be somewhat different. I intend to strip away all of the media hype and marketing stories surrounding Java, and present you with a monthly look at the real Java: Java at the frontline. We will look at the problems facing developers on a daily basis: things like playing around with classpath's, shipping releases to other platforms and database drivers. If any of you have particular problems you have come across and successfully resolved, and you feel would be worth sharing, please e-mail me. Or even if you haven't solved them yet, e-mail me anyway. I am always interested in hearing about other people's problems---there is a strange comfort to be had knowing others are suffering equally as much!

Before we go ahead into our first subject, let me take the opportunity here to thank Dolly Parton. While the Managing Editor and myself where thrashing out the idea for this column we came up with several names for it; we eventually agreed on "Straight Talking," meaning to tell it like it is. A few days later, I remembered that dear Miss Parton took the lead role in a movie of the same name. In the movie, if memory serves me right, she was a radio deejay answering listener's problems. So you can think of me as your new Java-Dolly ready to tackle the problems others dare not address. With that, I think I have now professionally peaked! Miss Parton, I salute you.

On that note, on to this month's address: trust.

Trust is a marvelous thing. It is the one thing that makes living that much easier. In order to survive, we trust things will work. When we pick up the phone, we trust it will have a dial tone. When we get into our car, we trust it will start. When we develop code, we trust it will work (well, I know some pray as well, but theology is beyond the scope of this article). The point is the majority of us take the approach that if something isn't working quite right it must be our fault, and we must have missed something. It is perfectly natural to do this, especially if you're new to the language.

But I will let you in on a wee secret---Java has one or two bugs! Well to be precise, Java is harboring at least 5000 bugs. At least! To be honest, it's expected. Let's take a quick look at the history of Java. It was first released approximately 3 years ago with a handfull of classes, compared to the 1000 odd classes that are proposed in the new JDK1.2 specification. This is a phenomenal growth rate. So, some teething problems are to be expected. But should we tolerate them? If it where any other company, then the answer would be no; but, credit where credit is due, Sun is making the effort (looking past the fact that they created the problem in the first place with their eagerness in having Java become accepted in the mainstream development).

Let me illustrate this with a simple problem that had one of our engineers here at N-ARY tearing his hair out for several days. Lawrence had spent some time developing a complete servlet database solution, using HTML. This servlet hooked into an MS-Access database and basically allowed the insertion and viewing of a database that evolved around chronological dates and rooms. For example, a user could book a room for a given day, say the 9th of December, for 2 hours beginning at 1400 hrs. However, a problem was discovered at the end of the procedure when the final booking was e-mailed to the room coordinator; instead of the 9th of December, it booked for the day before, the 8th. A strange error indeed.

The first natural thing to do was to look at the way the dates where being stored in the database. In this particular instance we weren't actually storing the date but the number of milliseconds since 1970. This ensured that no date mangling would have occurred on the database side. So onto the next stage of debugging.

Lawrence thought it might have to do with the servlet processing and the actual storing of the data. He worked on the assumption that somewhere in the chain the day was starting from 0, as opposed to 1. But again, nothing unusual came up.

Upon closer inspection we discovered that the problem was one of the classes from the core JDK. The code snippet shown below illustrates the formatting function we used.

public static String getDate(long _date){
SimpleDateFormat formatter = new SimpleDateFormat( "HH:mm:ss dd/MM/yy" );
formatter.setTimeZone( TimeZone.getDefault() );
return formatter.format( new java.util.Date(_date) );
}

The class, SimpleDateFormat, was the crux of the whole problem. Passing in our date, it incorrectly formatted the date, dropping a digit from the day value. This was a very difficult problem to find. Why?

Well, for starters, it is a common to assume/trust that the core JDK classes actually do what they say, and therefore you go off looking for the fault elsewhere. Only after a comical comment was made about the class was it investigated further, and sure enough it caught the culprit.

But is this an isolated case? Well, I am not going to advocate that you suddenly assume the JDK is wrong every time your class doesn't behave itself. The chances that a problem does exist with the core classes is rare. That said, a little known resource is available within the main Java Web site called the "Bug Parade." This forms part of the Java Developers Connection (JDC) located at http://java.sun.com/jdc. This section requires registration, but the good news is it's free.

This is the main area where bugs are submitted, and their present status can be viewed. For example, the particular bug number for the problem that we discovered is 4040985. The status for this bug can be viewed by directly entering the number and searching. If you do this you will see it has indeed been fixed, and has been updated in the 1.1.4 release of JDK. This information is particularly useful if you're experiencing problems and are unsure if upgrading your virtual machine will make any difference.

As a side point, when you install your new JDK version, remember to have a quick scan over the "changes" file that is deposited in the route directory of the installation. This file is often overlooked but contains all the bug fixes that this release promises to fix. So keep an eye out for it.

So what should you do if you believe a problem does indeed exist? First of all, you should check to see if you're the first one to have experienced the problem. You can do this by first posting a question on the Java Usenet group, comp.lang.java.programmer. You might even find me lurking around there. Generally somebody will have experienced something similar. If not, then go to the JDC and extensively search the bug database to see if your problem is the same as or similar to an existing bug.

If you find a similar one, then add your experience to the bottom of it (assuming it hasn't already been fixed in a later release). The more help you can give the engineers the quicker the problem can be reproduced, and hopefully rectified.

If however you discover that no one else has had a similar experience, then fill out a new bug form. It will ask you a series of questions, and ask you to describe the nature of the problem in as much depth as possible. This is an extremely important step. Give them as much information as possible. But before you do, make sure you can repeat the bug yourself. If you can't repeat it then the chances of an engineer repeating it are slim. Also, include sample code where necessary.

One of the more interesting aspects of the bug parade is the ability to vote for bugs. I am not convinced of the value of this concept. Basically, you can vote for the bugs that you would like fixed first. This is meant to be a general guide for the engineers at Sun to determine which bugs are causing the most grief. So it's important to check for the existence of the bug before posting a new one. It is better to have 1 bug with 10 votes, than to have to 2 bugs that are the same with 5 votes.

Conceptually it's a great idea; let the users decide which bugs are annoying them the most. But the system fails for the bugs that only a few people discover. These are placed last on the list of priorities and it may be several releases later that they are addressed. Sun indicates that they only use the votes as a general guide, and they don't always fix the ones with the most votes first. I am not so sure. But that said, there have been a good amount of bugs highlighted and fixed.

It's an interesting approach to take: having nearly all of the Java community become your beta testers, and reporting back their problems and experiences. It's a bold maneuver that appears to be working. However, Java still has a lot of problems that need attention before we see it controlling medical equipment. But I think I would prefer to take my chances with a Java controlled heart monitor as oppose to a Microsoft NT solution.

Sun has a completely different approach to their developer community than say the likes of Microsoft. When we here at N-ARY had discovered a problem with the JDK we sent an email to Sun indicating our concern. They acted fantastically. They took our problem and worked with us to a successful conclusion. We can't ask for much more than that.

So the moral of the story? Don't believe everything you read on the computer screen. If a problem is still persisting and you've exhausted all avenues, then take a look at the classes your utilizing. Don't assume/trust that just because they are part of the core JDK that they work. Sometimes they don't. Don't be afraid to challenge the classes. Ask around, see if anyone else has experienced the problems. You may be surprised.