Getting Productive with Java

You've done the java training course, you've compiled small java programs, but you don't know how to assemble and manage a substantial java project. This article explains what basic construction tools I use and why I've chosen them.

There are many tools available for Java development. Over the years I've used several, expensive, big IDEs. Most of them were bloated, buggy and oversold. I prefer tools that are relatively small but allow a greater degree of customisation by the programmer.

To be productive with Java you need three tools:

Build tool

Compiling individual class files on the command line just isn't practical in real projects. You need a tool that will automate compilation and packaging of class files. I use the ANT tool from the apache software foundation's jakarta effort to do this. ANT can be used to manage compilation of the entire project just by launching a single command line.

In addition to controlling compilation, java GUI applications, web applications and applets are packaged into archives so that the entire unit of work can be deployed as a single file. (Java GUI applications and applets are packaged as .jar files and java web applications are packaged as .war files.) Ant can be used to build these archives. Ant can even be used to build .zip file distributions, javadoc files and even drive the construction of entire websites like this one ;-)

Reasons to use Ant rather than an IDE-specific tool

IDE

I prefer IBM's eclipse tool. Rather than concentrating on flashy features (such as the usual rubbish-generating "wizards") the eclipse team seem to have concentrated on features that help with agile development such as refactoring, JUnit testing integration and a "scrapbook" where blocks of Java code can be tried out on the fly. Erich Gamma (of design patterns fame) plays a prominent role in the development of eclipse, so it's no small wonder that the tool developers have concentrated on useful features rather than flashy ones that appeal to technology fashion victims with large chequebooks. Eclipse runs on Windows and Linux and is still relatively small in size.

Test-Driven Development

JUnit is an automated unit testing framework for the Java language. Most people first think that "extreme programming"-style unit testing is about testing. It's not. You're supposed to write the test before writing the code. When you've written the test you then compile it and try to get it working. By doing this, you're expressing your design in each test case. When I first tried using Junit I found it enormously stressful to write tests before the code (it felt as though I was spending a lot of time up front writing code that wouldn't ship). The good news was that design work got easier because I could quickly see the implications of changing something by running the tests. It's really nice when you have to locate a bug - you don't have to try to think up and run all sorts of manual tests - with a single click you can systematically tests the entire code base.

Rather than writing separate little "main bodies" that demonstrate isolated functions of your codebase, JUnit can be used to build a tree of tests that can be automatically run and checked. Since the process of running tests and checking test results is completely automated, you can run your tests all the time. Bugs in your codebase need only ever be found once. After that you should write a test that demonstrates the bug. Fix the bug and re-run the test. If it passes you know that the test is actually monitoring the conditions that you corrected. Integrating this test into the test suite for the entire codebase prevents the silent recurrence of the bug.

Popular excuses for not unit testing:

It's amazing how many pundits and "architects" are prepared to debate the theoretical limitations of test-driven development having never tried it themselves. Talk is cheap.

Some people act like you either know test-driven development or you don't. I think this is wrong. It's a matter of practice and experience. I've been programming test-first pretty much full time for the last two years and I'm still finding it challenging. It was a difficult thing to start doing, but I have found it gets easier over time.