Java Reference
In-Depth Information
you decide to break a class into two different classes or split an interface, these IDEs can make
the change throughout your code. Lots of tasks that used to take a script utilizing
find
and
sed
(and a day or two of debugging said script) can now be done in the IDE. The advantage is
that the IDE actually knows something about the language being altered, and so can do a far
more intelligent job than the scripts could do.
IDEs are a great help when writing your own code, but they are invaluable when you are read-
ing code written by someone else. This is because the IDE provides navigation functions that
can't be provided by a simple editor. IDEs scan and parse an entire set of related Java files,
and can be set up so that all of the dependencies of a particular program can be included in the
scan. From this, the IDE can form a dependency tree of the entire program or system. This al-
lows navigation directly to the source that declares or defines some other class. When hunting
through code that you didn't write (or that you wrote some time ago), these navigation aids
are invaluable.
The IDEs will also let you maintain the build files for your system (and let you use any of the
usual suspects for building, such as Make, Ant, or Maven), and let you run and debug your
system from the editor itself. All of which is highly convenient, saves time, and can help you
avoid the problem of finding a bug within the debugger and then forgetting exactly where that
bug was when you switch over to your editor.
In fact, these IDEs have introduced into the Java environment the kind of programming sys-
tems that users of LISP used years ago and were the basis for those folks claiming the inher-
debug, with each phase being separate and each requiring a different set of tools (and each
phase being separated by considerable chunks of time), the IDEs now available merge the edit/
compile/debug cycle into a continuous workflow. Programming becomes far more interactive,
since simple mistakes can be caught on the fly. Even better, design decisions are far easier
to revisit, since you can refactor your code with the aid of the tools and hence don't pay the
kinds of penalties that we used to pay for making a bad decision early on in the development
process.
All of these advantages accrue even if your development is (like mine) low-level system code.
If you are doing development using one of the many Java frameworks or containers or are
building graphical interfaces, the IDEs are even more of a laborsaving device, as they have in-
tegrated tools that will generate most of the boilerplate code needed for these tasks. Not using
these tools when doing such tasks is like trying to start a fire by banging rocks together.
This is not to say that everything is perfect with these tools. I have had, well…interesting ex-
periences with the way IDEs interface with revision control systems. The view of what code
