Introduction to Java Debugging
What is java?
Obviously we?re not talking about the warm, dark, caffeine loaded
drink one buys at a coffee house. This section reminds us that
java, the language, is just that, another programming language
(albeit, a very powerful one).
Java, as a programming
language, has been around for a number of years. In fact, it was
conceived in 1991 under the name ?Oak?. Then, it was envisioned to
be a language to control consumer electronics and, through various
events, including the adoption by the WWW community (most notably by
Netscape in 1995) and various alliances, grew into ?? a portfolio of
products that are based on the power of networks and the idea that
the same software should run on many different kinds of systems and
devices? according to Sun's official site on java.
Also according to Sun,
"java technology readily harnesses the power of the network because
it is both a programming language and a selection of specialized
platforms. As such, it standardizes the development and deployment
of the kind of secure, portable, reliable, and scalable applications
required by the networked economy.? and, 'the java programming
language lets you write powerful, enterprise-worthy programs that
run in the browser, from the desktop, on a server, or on a consumer
device.? A final note to the history of the java language; it is
well known that it has been one of the most rapidly adopted
languages ever created.
Why is all that
important? Consider the major points; java has been adopted very
quickly and is very flexible and powerful. That adds up to
complexity that adds complications that, if not planned for early in
the lifecycle, can lead to misunderstandings and confusion.
Clearly we know about java, or we wouldn't
be reading this book. However, java, like other programming
languages has some common properties.
A Quick Summary of Software Properties
In the following
paragraphs, general software properties are examined and correlated
to five major issues that can occur during the code and test
What Software Is:
Loads of fun
What Software Is Not:
A ?Dark Art?
A reason for delaying projects
An excuse for over budget projects
Fun to manage
It is common to see
the software development portion of a venture become the scapegoat
for all the trials and tribulations associated with late delivery
and over budget projects. Software developers, who take the brunt
of the blame, aren't stupid or lazy, and, if we are to assume they
have received adequate design requirements, not deliberately
creating the ?wrong? thing. They enjoy their craft; it's what they
do and the majority strives to do it right. So what's happening?
It is all too familiar
to hear the tale of a programmer dutifully slogging away at his or
her terminal writing line after line of code to the specifications
that have been given. There's a time limit, the developer doesn't
have time to comment every line of code, so something that's
?obvious? is usually left unremarked and documentation may be
sketchy. That's the first mistake. The code is then compiled, if
it compiles on the first attempt and looks to meet the requirements,
off it goes to test and QA. Second mistake.
The tester fires it
up, looks at the requirements and determines it doesn't match or
doesn't work in one way or another. Since the code itself seems
arcane, it's hard for the tester to say exactly why it's wrong, just
that it is. Back it goes to the developer with an admonishment that
it doesn't work, sometimes with why it doesn't and occasionally not.
Third mistake. The developer looks at what he or she has been told
to build, looks at the testing notes and tries again. Fourth
mistake. Changes are made and the code sent back for testing. This
is the fifth, and final, fatal mistake. Why? Simply because the
process will reiterate itself many more times than is necessary
until the finished code complies and runs with what the testing team
Most likely, that will
be when it's late in the project schedule. Then the blame starts
with the project office being yelled at by management, who, in turn,
bellow at the testers, who point the finger at the developers.
Depending on the developer, they either run back to their cube for
more cold pizza, warm cola and late nights or, design new levels for
their favorite first person shooter game (probably involving the
project office) or, start looking for a new job. As stated above,
managing software projects is anything but fun.
It is probable that a
good number of you reading this book have either seen or had this
happen on your projects. If you haven't, you either haven't had a
lot of experience with software development projects, yet, have been
extremely lucky, or already benefited from the some of tricks, tips
and techniques this book will endeavor to make clear.
In the generalized
(and java specific) approaches described in this book, we attempt to
demystify the art and craft of java debugging and testing, reduce
cycle times and, if not exactly making java project management fun,
it should be more bearable. The remainder of this book details the
above five missteps, what they are and how to avoid (or at least
limit) their impact to a java development project.
We?ve discussed java and general software
properties, now let's examine a bit about debugging and testing in
Java Testing and Debugging Philosophy
In general, testing
and debugging have always been unpopular topics. Although one may
have been given some ideas about testing and debugging in various
computer language classes, the topics are either learned from your
mistakes or treated very fleetingly. There are very few, if any,
college courses dedicated to software testing and debugging as
standalone subjects. There are a number of books on the subject,
but they either cover well-known languages (such as C++) or are very
generalized in nature, concentrating solely on metrics. In fact, it
is recommended that the reader understand some of the general
principle of test and debug techniques since this book is specific
to the java language.
The last thing we want
as a project team is to unleash a buggy, badly documented
application on an unsuspecting user. Unfortunately, it still
happens more often than it should. Why? It happens for several
reasons; not enough testing, not enough time for developers to
clearly comment and document code, and inadequate resources
allocated to the debug-test-recode cycle. If there isn't enough
time to do it right the first time, there better be enough time to
fix it. If it becomes necessary to issue bugfix releases of an
application (even on large projects) it means something wasn't done
right the first time. It's painful, embarrassing and lowers
credibility. Hopefully what you learn from this book will help
alleviate having to work on bugfix point releases so you can
concentrate on enhancements for the next big release.
There are further
issues with released applications. Someone once said, ?If you write
fool-proof code, they invent a better fool?. Believe it or not,
this can happen. The good news is, there are ways to make your code
closer to foolproof )or at least test for it). There is also the
issue of platform dependency; very little code targeted to a
specific class of machine will run on another class of machine. For
example, device driver authors spend a lot of time adapting and
changing their code as new machines become available. Fortunately,
java is, for the most part, not highly platform specific (although
there are some issues that are discussed in a later chapter), which
is a big plus for using it.
technology professionals are aware of the value of testing and
debugging, but few devote a reasonable amount of resources to
implementing it. This is likely because they believe that 'their?
code is either too simple to warrant the time or too complex to
allow multiple paths to be tested. Unfortunately, the former
assumption gives a false sense of security, and the latter, a
pretext for discounting the process. Both of which naturally wind
up producing bad applications. Another important goal of this book
is to impress upon the reader the absolute necessity to test each
and every piece of code you can; the more you test, the less likely
bugs are going to get out with your applications.
Overall, it is up to
the project team to ensure that they do all they can, within the
resource limits given, to communicate test and bug issues as quickly
and concisely as possible. Working together is the only way to
diminish the appalling possibility of sending out a defective