Build Better Java Applications

In 2000, my friend Spencer Marks and I summarized some best practices for building Java applications in a presentation that Spencer presented at Software and Internet Quality Week Europe in Brussels. We would have presented it together, but I was in the room next door giving another presentation. Here are our slides, Building Better Java Applications, and here is fresh criticism of some of the points we made, based on six more years of experience building Java-based applications:

  • Best practice: UML: Together/J is now Borland's Together. I used the high end version of Together for a few years, and it completely changed the way I developed software applications. The aggregate set of tools in Together made me look smart. Unfortunately, it was very expensive, and it was too difficult to convince my subsequent employer to pay for it, so I stopped using it. I still haven't found a better overall design tool, although some of the tools in IntelliJ IDEA cane make you look just as smart.

  • Best practice: Jikes: I still admire Jikes' adherence to the Java Language Specification. With the advent of ant, some of the other arguments (fast compile time and cross-platform builds) don't hold up as well.

  • Best practice: Builds: make never was a good way to build Java applications. Ant is great for cross-platform builds. Some of my friends advocate Maven for large projects.

  • Best practice: Check in often: This should be called "Integrate early and often." I now use subversion; it is clearly better than CVS.

  • Best practice: Standard library: This could be expanded to a diatribe against the antipattern, "Build all your own infrastructure." Jakarta Commons contains many of the tools application programmers need every day.

  • Best practice: Java idioms: In the Java 5 era, the idioms are a little different. We like for loops again—foreach is the best way to iterate over a Collection. Generics are great for type safety—use them! Just by adding generics to your legacy code, you'll find and fix lots of bugs. java.util.concurrent is great if you need low level synchronization—don't roll your own!

  • Methodology: Refactor often: Today, tools like Eclipse make refactoring easy and painless. I don't know how we got any work done without it.

No comments:


Related Posts with Thumbnails