Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Life outside the IDE

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

By Nathan Hamblen, JavaWorld.com, 12/18/07

Page 2 of 4

Editopia

The fundamental coder's tool is one for editing code. Endless Internet wars -- the traditional kind, with no stakes at all -- have been fought over which is best. Everyone can and will continue to use whatever editor personally feels right, with largely no effect on anyone else. The one thing almost everyone agrees on is that no IDE has a general-purpose text editor that is worth using independently.

Because of their breadths of purpose and long histories, text editors are a software crop that has flourished even more variously than Java IDEs. They've put down healthy roots in every computing platform, so they have no need to concentrate resources on a base application in Swing, SWT, or any other cross-platform interface kit. Instead, general-purpose text editors can concentrate on using underlying platforms to their greatest potential.

In choosing an editor, you should look for one that stands at the top of the pile for whatever computing platform you prefer. Don't fall for the geek-snobbery that demands that everyone who wants to be taken seriously must use one of two legendary editors designed for text consoles. Either you're already one of those people running a Unix-like OS with Ratpoison, or you're in the large majority of the population that appreciates a well-designed graphical interface. Click with pride.

Other than platform integration, the most important quality in an editor is customizability. At a minimum, you should be able to edit the bindings of command keys to internal macros and external shell scripts. Most editors allow the definition of syntax coloring for any programming language expressed in text. Because of this easy expandability, support for languages and markups can be added by amateurs; scriptable editors reach into leading-edge and niche technologies faster than IDEs, and without all the crashing that comes from alpha plug-ins running at application scope.

TextMate is the editor I use in the example here, but it certainly isn't the only good choice; the Mac OS X platform alone has at least a half dozen top-tier editors.

Back to building

You've opened your project folder in a text editor and are looking at some syntax-colored Java source file. Now what?

Look around for ways your text editor has improved the ancient art of text editing that IDEs, in a rush to pile on glitzy features, may have overlooked. For example, TextMate has the ability to set soft tabs, with spaces that act like tabs as you move the cursor through or delete them; that subtle touch quietly ends the tabs versus spaces debate by giving you the best of both worlds.

Triggering a compile without leaving the editor is easily accomplished, so long as your project is serious enough to use an external builder. Many editors have some built-in support for running Ant; to use builders not already supported by an editor, it's time to explore its expandability options.

TextMate comes packaged with a number of bundles. These can be easily edited or created from scratch, copied from one installation to another, and distributed on the Web. Each bundle can have shell scripts bound to command keys, among other things.

The best way to display extensive script output in TextMate, as from a build command, is by HTML. That sounds like it might be difficult, but TextMate makes it easy and worthwhile, turning errors and warnings into links back to the source lines referenced. Consider the command in Listing 3, cobbled together from a few included with the program.

Listing 3. A command to run Buildr from TextMate

. "$TM_SUPPORT_PATH/lib/webpreview.sh"
    html_header "Building \"${TM_PROJECT_DIRECTORY##*/}\"..."

    buildr  &> >("${TM_RUBY:-ruby}" -rtm_parser \
      -eTextMate.parse_errors)

    html_footer

This outputs a header, then the buildr command piped through an HTML converter supplied by TextMate, and a footer. In Figure 3, it's bound to command-B for any Scala or Java source file.

Figure 3. Bundling a Buildr command (click for larger image)

The command runs Buildr, a builder that's compatible with Maven's local and remote repositories. Buildr is based on Rake, so its build instructions are Ruby scripts that can be directly hacked, not structured XML tied to plug-ins. It can also be a good deal faster than Maven, an important consideration when you're building frequently from an editor. But because Buildr's dependence on Ruby and Rubygems might be an unwanted complication for some Java-only projects, the example project distributed with this article includes Buildr and Maven descriptors that do nearly the same things.