HALT! Just stop right there! You've probably stumbled across this column while merrily thumbing through this magazine, and you're now wondering what this lump of words is all about. You may have noticed this column in previous issues but couldn't be bothered to read it. After all, who'd blame you, since there aren't any pictures or fancy diagrams to support it. It's got to be dull, right?
But why not be daring? Go on, lend me 10 minutes of your time and let's see if I can entertain you as I give you some Java enlightenment. If you don't like it, then hey, I won't hold it against you. We won't even speak of it again. Deal?
Well, last month saw me in Tokyo. Again. I was there giving a series of talks on the merits of using Java at the server side. The talks were geared around Java Servlets and the benefits they can offer over and above alternative technologies such as CGI or Microsoft ASP. The presentations highlighted and talked listeners through many of the large-scale case studies that we (here at N-ARY Limited) have installed. At the end of each talk there was an in-depth question-and-answer section. And that's where the fun began.
But before I continue on to the core of this month's column, it's time for that characteristic-parallel thing to occur. This is where I take a personality trait and apply it to our consciousness of Java. This month I'm going to go for inquisitiveness - the trait of continually asking questions.
Inquisitiveness is something we're familiar with when we're young: "Mum, why is the sky blue?" and "Mum, where do babies come from?" As soon as we develop the ability to speak, we start learning. Learning is achieved by looking and pointing at things and continually asking what must seem like silly questions to our parents. It's a shame, but most of us lose this quality somewhere in puberty.
Back to Japan
So after a two-hour presentation on the merits of Java Servlets, I was all geared up for a whole host of questions on the Servlet API. Maybe some questions on how to handle special HTTP requests or about different browsers. Maybe even a question on how the Servlet API is used within application servers. But what I thought and what I was asked were two different things. I think, in all honesty, the percentage of questions asked on the Servlet API was around the 5% mark. The remaining 95% was on basic Java principles. I thought: How wonderful.
As discussed in this very column a number of issues ago (get the back catalog - a sound investment!), the software industry in Japan isn't as far along as its consumer electronics. They're still very much at the early adopter's stage of development - which is actually good. They haven't suffered the same side effects of continually moving JDK versions as we have, since the majority of them started on 1.1.
So there I was, promoting the whole Java Servlet thing, hoping to persuade people to not go down the CGI route of development, and what they were asking about was fundamental Java. I met a lot of developers in Japan and nearly all of them asked me the same question, "What do you use to debug servlets?" This line of questioning surprised me. At first I thought it was just the one time, but when the same question was posed a second and then a third time, I thought: Okay, maybe we've missed something in our teachings.
The answer I gave them was simple and took many of them back a bit as they thought I was joking: use System.out.println(...). This is the most sophisticated debugging tool I've ever used. It holds many advantages over many other techniques, in that it's completely portable and it doesn't matter which virtual machine you're running on - or which platform. It will work. It's simple - nothing too complicated and you don't need to worry about exceptions. In a forever increasing world of complexity, the ability for simplicity to shine through still exists.
Back in my old days of coding C and C++, and after my university years, I had the pleasure of working with a mentor who taught me a thing or six about real developing. The months I spent with him changed my whole outlook on development forever. I thought: Why couldn't they have taught this in university? Dave Forth was his name, and he believed that debugging tools were only there for lazy developers. Now at the time I was a big fan of Turbo C and its inline debugger. The ability to trace through execution steps was a godsend for me. So, to have this man turn my world upside down by dismissing debugging tools, I thought: Oh no, I'm lost now!
But you know, the more I thought about it, the more he was right. For example, you don't see house builders using debugging tools. The house either stays up or comes down after the first storm. After a house has been erected, the master builder doesn't clear the building site and start up a house debugger. (What a house debugger might actually look like staggers the imagination.) So how can the builder be sure the house won't fall down?
Well, one of the new waves that's gripped the developing community in recent years is that of object orientation. We've all experienced objects - you can't develop Java without being aware of them. One of the goals of an OOD (object-oriented design) system was to reduce the complexity of a system and thus make it less prone to errors. A good OOD system shouldn't require that much debugging. After all, you're developing small units that can be individually stress-tested. But it's not a new way of operating. The computing industry has just taken an old idea, given it a fancy name and heralded it as the new and improved way software should be coded.
Industries have been practicing OOD for hundreds of years. Let's look at our builder again. It's a perfect example of OOD in the real world. The builder doesn't build each individual brick. Nor does he test the strength of each brick. He's already bought into the technology (yes, even a brick has technology, i.e., the technology to engineer it to the standards that are suitable for building). Now he places these bricks together in the manner in which the bricks' API has determined for how it's going to interact with other bricks.
Anyone who's played with Legos or any other small building blocks when young knows that to build a strong wall, you don't place the blocks one on top of each other. Instead, you interlace them. This is a brick API (or definition) of how you can best use a brick.
The builder uses many such materials, and it's the skill and knowledge of the builder that determines how bricks and other materials go best with one another. But he knows that once the brick is put in its place, he doesn't need to worry about it again, i.e., he won't need to debug that brick at a later date. Granted, there are builders who aren't particularly skilled at this, and I'm sure some sort of house debugger would be a godsend to them.
But what if something does go wrong with the house? What can the builder do? Well, an experienced builder would know what to look for in order to fix the problem. He'd spot the telltale signs. Well, there's no reason why a developer can't operate on the same principle.
But it's relatively easy to find problems in a house. You can walk around it, get inside it and discover the problems. What can a developer do? In order for the developer to be able to fix a problem, he must first try to find it. But many fixes only solve the symptoms - not the problem. For a developer to see what's going wrong, he must see how sections react, how variables are changed.
And you can do this with a debugger....
Yes, you can - there's no denying that. But as the physicist Leo Szilard questioned in 1929: "Can you know all about the world without changing it?" He was talking about thermodynamics at the time, but the same thing applies to our world. It's like any measuring tool - it's never completely impartial. The very presence of the measuring tool creates a disruption in the natural flow. For example, a small turbine placed in a stream to measure flow rate will offer a small amount of resistance to the stream. Granted, this small resistance may never be detected, but just because it can't be measured doesn't mean it's not present. Software debuggers are the same way.
Have you ever tried to solve a memory leakage problem or a threading problem with a debugger? Ever wondered why you could never reproduce the problem within the debugger, but as soon as you ran it on its own things suddenly started crashing? Or even worse, you're developing as you go along within the debugging environment, only to experience weird and wonderful crashes when it's run stand-alone?
This is because the very presence of the debugger has introduced a new unknown element to your environment. An unknown constant that you've no control over is infecting your world. It sounds a bit drastic and melodramatic, and it won't be the case for every single bug you're trying to track, but why take the risk?
Back to our builder. Once he's spotted the error, fixing it is generally not a major deal, unless, of course, he's spotted a fundamental flaw in the overall design of the system. For example, maybe using paper-based bricks for the foundation wasn't that great an idea after all! The developer needs to gain the same insight.
The simplest way for the developer to discover problem areas is to try to insert one of the least intrusive tools possible: System.out.println(...). For example, Java has given every object the ability to print to string through the java.lang.toString() method. But how many of you actually override this simple method in your classes? I'd guess very few. To those of you who don't, why don't you? You can place a whole host of useful information about the classes state in here, so should the day come that you need to print out some information, you can simply make a call to your toString() method without worrying about littering your code full of System.out.println(...) statements.
It's this simplistic view of looking at things that generally yields the quickest results. You have to be inquisitive with your code. Learn to ask it silly questions and who knows, you may be surprised at what answers come back. As the textbooks say, it's about 95% design and 5% coding (...and 70% debugging!). By using the inherent tools Java has provided, we can hopefully remove this unwanted 70% - or at least reduce it significantly.
Since this is the beginning of a new six months, I thought I'd introduce a new section to the bottom of each column. Over the last six months we've addressed many different issues ranging from development to running a complete Java business. I'm a single voice in a sea of noise, so I'm going to recommend a book to you each month. Each month the book will have relevance to a column that was previously in my "Straight Talking" series.
To start this mini book review off, I'm going to recommend a book I purchased on University Drive in Palo Alto while in California earlier this year. This book complements my past column on start-ups, (JDJ Vol. 3, Issue 10). Losing My Virginity by Richard Branson is an autobiography showing the rise of Britain's top businessman and his empire, Virgin. It's a fascinating read and very inspirational to anyone thinking of starting a new business venture. Branson is extremely honest, admitting to his mistakes and how he'd probably do things differently if he had the opportunity.
It was interesting to read how a noncomputing empire was built with the same ethic that many developers hold dear to their hearts - business should be fun, and not all shirts and ties.
About the Author
Alan Williamson is CEO of N-ARY Limited, a UK-based Java software company specializing solely in JDBC and Servlets. He recently completed his second book, which focuses on Java Servlets. Alan can be reached at [email protected] (www.n-ary.com).