Life outside the IDE

Coding in a parallel toolset has its perks -- freedom, for one

For many Java developers, the IDE is more than a high-powered telescope, it's the Milky Way itself. In this article Coderspieler Nathan Hamblen reminds you how invigorating it can be to write code the old-fashioned way -- by typing in a plain text editor and building with an external script. Not only will this old-school skill save you valuable time when your IDE goes awry, it could be your ticket to learning about newer technologies like Buildr, Jetty, JavaRebel, and more.

Nothing has done more to shape the experience of contemporary Java programming than its set of popular integrated development environments, or IDEs. As was true for C and C++ code, the benefits of editing Java code with feedback from a compiler and debugger are many. Compilation errors can be located visually rather than by line number, and execution attached to a debugger can be stepped through without a context switch -- and those were 1.0 features.

Java as a platform has benefited enormously from its ecosystem of user-expandable IDEs. NetBeans and JBuilder set the bar initially with their support for plug-ins that added functionality, and IntelliJ IDEA distinguished itself with refactoring tools, but Eclipse swept the market by being expandable, free, heavily featured, and, thanks to its SWT framework, indistinguishable from standard Windows applications. (When Eclipse was first developed, Swing showed little hope of becoming satisfactorily responsive or seamless.) Eclipse and its base of plug-ins grew so quickly that JBuilder rebuilt itself on the platform, but other IDEs that held out now profit from a Swing toolkit that works almost as well as -- or even better than -- SWT, depending on the platform.

A fall from grace

It's a curious turn of computing history that, just as the mass market had finally converted to protected-memory operating systems, programmers themselves began to work in an environment devoid of program isolation. For most Java programmers, Eclipse is effectively the operating system. It's the application you open first and use for almost every part of your work; it can have software added to it, executed, configured, and removed. But as an operating system, it's particularly shoddy. Even the non-OS Windows 3.1 was able to load and unload software without restarting, but as Figure 1 shows, Eclipse cautions the user against taking such liberties.

Eclipse may need to restart
Figure 1. Eclipse may need to restart (click for larger image)

And though live installation of plug-ins might not be a practical concern, the fact that plug-ins are not sufficiently isolated for the operation leads directly to them bringing down the ship when things go awry. Some plug-ins are incompatible with others and refuse to work at all; some become gremlins that cause visual quirks and fiendishly crash the entire VM (just as you're really getting things done). To eliminate the suspected troublemaker, you must often find and delete dozens of packages from the filesystem.

Along with fending off stability gremlins, a fair amount of effort is required to configure software that comes with such an eye-popping array of features and has the capability to add infinitely more. It's easy to spend an entire day getting things just right -- a day that could easily be lost if the installation goes south. A Java IDE is nothing if not high-maintenance.

Counterculture

Even when an IDE is working swimmingly, you might still reasonably doubt that its automating features are without a downside. It's handy to have a tool that generates getters and setters, the six lines of baggage that travel with every bean property. But that such features are universal to Java IDEs has blinded us to weaknesses of the language and the downsides of boilerplate code.

Some examples are subtle. In the Wicket framework (see Resources for a link to this and other tools discussed here), values are bound to components with an implementation of the IModel interface. Thanks to anonymous subclasses, it's possible to instantiate a model in place that makes use of the current scope. Given integer fields a and b, we can create a read-only Label that displays their sum, as shown in Listing 1.

Listing 1. Binding a Wicket model with an anonymous subclass

new Label("sum", new AbstractReadOnlyModel() {
      @Override
      public Object getObject() {
        return a + b;
      }
    });

This pile of code is largely IDE generated. AbstractReadOnlyModel is supplied by name completion and auto-imported. Once you open the braces for its anonymous subclass, a getObject() method returning null is suggested; you need only supply the body. It's easy to go through the whole exercise without considering that the mandatory words public Object getObject() say little about this particular label. If you have 100 labels with 100 different ways of deriving their values from a and b, you will have 100 lines of that same signature.

Because this boilerplate is so easily generated, its problems are not concretely felt in the fingers, but the detriment to readability is very real. The eyes must filter out numerous passive symbols to process the effective few. If Java supported first-class functions, we could significantly improve on this approach by reducing the code to its unique logic, seen in the slimmed-down Listing 2. (The listing uses Scala syntax, which we'll discuss in more detail towards the end of this article.)

Listing 2. Binding a model with an anonymous function (Scala syntax)

new Label("sum", () => a + b)

Aside from their role enabling a boilerplate stalemate, IDEs can unwittingly stifle the adoption of new technologies. Because users have become accustomed to built-in support for everything, anything that requires external software -- particularly anything using the command line -- is removed from serious consideration. Up-and-coming projects are distracted by the need to either make an appearance inside Eclipse or be invisible to users. Advances in dependency management, for example, have been slowed by the GUI-bedazzled conviction that the process depicted in Figure 2 is an efficient way to add and upgrade dependencies.

Managing dependencies by mouse
Figure 2. Managing dependencies by mouse (click for larger image)

Mixing in

This isn't to say that we should delete our IDEs and go back to painting machine code on cave walls; still, it's a good idea to go outside and breathe every once in a while. There are other applications to enjoy, other directories outside of workspace/, other languages than Java. Freedom to work outside the IDE is freedom to explore new things, long before they can be smoothly used (or used at all) inside a preferred IDE.

By maintaining a parallel toolset, you can have that freedom and be better prepared the next time your IDE mega-widget self-destructs. The best thing about smaller tools is that they're replaceable, and simple enough that replacement is not often necessary. In a worst case scenario -- not that those ever happen -- you may need to fix a critical bug with nothing but an ssh terminal, and that will be a lot easier if your brain cells aren't atrophied from exclusive use of the IDE cheat mode.

This article describes a handful of the many independent programming tools available. Its accompanying example application, called calc, is a testbed for experimenting with these tools. The Java version of the summing model above is from calc, as well as the source code and markup that appear below. (You can download the complete code from the Resources section.)

1 2 3 4 Page
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more