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.