| By Jim Milbery |
Article Rating: |
|
| March 1, 2002 12:00 AM EST |
Reads: |
14,608 |
Welcome to the first installment of JDJ Labs. Our
goal is to introduce you to commercial (and open-source) products and technologies
that will help you, the Java developer, work more efficiently. We expect
our testing to provide you with a starting point for your own testing and
analysis. In this column we’ll be looking at common market trends that affect
the commercial products and services in the Java space.
Over the past few years we here at JDJ have looked at quite a
lot of Interactive Development Environments (IDEs) for Java programming.
IDEs provide a sort of one-stop shop for software authoring, compiling, and
deployment. Historically speaking, software programs used to be written using
a regular OLE text editor. These original editors treated text documents
and code the same way – as text. Specialized text editors assisted programmers
with the job of writing and editing code.
Even many popular 4G languages make use of a text editor as the primary
programmer’s interface. It was the emergence of graphical user interfaces
(especially Windows) that fomented the emergence of the full-blown IDE. This
new breed of IDE handled all aspects of programming – development, coding,
debugging, testing, and deployment. Over the years the graphical IDE has
become a de facto standard of sorts. In fact, all the leading tools and database
vendors were quick to release their own graphical Java IDEs almost as soon
as the Java revolution began.
The question that faces us, however, is whether or not the graphical
IDE is a good thing. On the one hand it provides a one-stop shop for programmers
to gain access to all the necessary parts of a programming language. On the
other, graphical IDEs tend to insulate the programmer from having to understand
all the ins and outs of a particular language. Personally, I believe it’s
important for a developer to have a firm understanding of the underlying
language (especially when that language is more of a platform – like Java).
I don’t mean to imply that a programmer needs to have an intimate understanding
of the internals of each and every class that they use. (After all, one of
the premises of OO development is the ability to rely on the published interfaces
of an object.)
The problem, to my way of thinking, is the degree to which most IDEs
insulate developers from their code. For example, graphical IDEs are filled
with wizards that take care of the common tasks a programmer faces. You want
to build a Swing-based data entry form for a table in a database? Just use
the form-builder wizard. The problem with this approach is that the programmer
may never understand the logic used to generate this form. Generated forms
rarely meet 100% of your needs, and the novice developer winds up trying
to modify a complex set of Java code that was created by the wizard.
Wouldn’t it be a better long-term approach for this same developer to
build his or her first few data entry forms from scratch and learn the ins
and outs of Swing and JDBC? I’ve also heard experienced developers weigh
in with the argument that most IDEs just “get in the way” when it comes to
Java coding. To be sure, some of this comes from the age-old adage that “real
programmers use vi or Emacs, or <insert your favorite text editor here>.”
However, there is a nugget of truth here as well. My question to you, dear
reader, is where you stand on this issue. To IDE or not to IDE – that is
the question!
• • •
Send your comments to jdjlabs@sys-con.com.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
