Developers are very good at writing their own tools and so one can find a lot of high-quality free software for developing and maintaining software. I've found that I can create a first-rate development environment in about a half a day with entirely free and open-source software.

• CVS - Version control for Unix and for Windows
• Eclipse - Full feature IDE
• MySQL - Enterprise class Database
• Apache
  • Tomcat - Mature web services environment
  • Ant - Simple Make Tool
  • Tomcat - Application Server
  • Struts - MVC Library
  • Log4J - Logging Framework
• JUnit - A Way of Life
  • Mock Objects for Struts - Test-first for MVC
  • HttpUnit - Not for Unit Testing at all, but Useful

The above list covers the core software that any enterprise environment should be using. I've left out bug tracking, because I've generally used in-house bug tracking systems. It is an easy application to implement, so I'm sure that many good open-source bug tracking software is available.

If there isn't an existing version control system, installing a version control should be the first step of implementing an enterprise environment. As you add features and functionality to your project, you will invariably make a mistake and want to look at exactly what changed. Having a nice version control system makes this easy. Because CVS is free it integrates many IDEs. In fact, since about 2000, I've come across an IDE that doesn't come with a CVS integration.

The development environment should always support a very low-tech build. If you can only build in the IDE, then you probably need a human to do the builds, everyone has to use the same IDE, and you will someday be hamstrung by the capabilities of the IDE. Ant is great because it is low-tech. I can have a development environment with VI and Ant and be quite productive. I can also automate my builds and tests.

I've sworn by many Java IDEs. First it was Borland JBuilder, but the licensing became draconian and too expensive. Then I switched to IntelliJ, which was cheaper, and had great refactoring features. Recently I switched to Eclipse as I started working with more educational and not-for-profit development shops. I find that it doesn't matter what IDE I use, as long as I know it very well. Since Ecplise is free you can download and use on any project - no matter what sort of monetary or bureaucratic obstacles you might have.

If you are already using an enterprise-class database, ignore this step. I usually use Oracle and recommend it if you can afford the licensing, but MySQL is good, free alternative. Also, if you are being hosted by a third party, chances are that they use MySQL and not Oracle. Yahoo, for instance, includes MySQL database access in its standard web hosting product.

Tomcat is a good J2EE environment because it is simple and you can design web application software that focuses on doing the job.

Tomcat is by no means the only good servlet container. I am a big fan of Oracle Application Server, which is based on Orion. Orion is free for not-for-profit use.

I suspect that any of the application servers on the market right now are all rather good. My biggest gripe with J2EE is that there are a lot of unnecessarily complex APIs. My experience is that the simple implementation of the Struts MVC architecture using servlets is easier and faster. Don't bother with EJB, RMI, or the XML apis. They are really more trouble than they're worth. (For XML, use the struts digester class. Its effective, fast, and easy).

Struts is now the standard for the MVC in Java. It is simple to learn and easy to maintain. I use nearly aspect of Struts regularly. The template facility allows me to create modular JSP templates for a really clean, nice corporate web portal (the latest release calls them tiles (why can't developers just leave well alone - templates were fine). The HTTP connection processing code allows me to take a request, read the values from the form, do database queries and update the form. And the XML Digester is a very simple and powerful way to handle XML.

Usually I like to use the internal java classes, but not in the case of Log4J. The logging API in java has some serious flaws and one just has to wonder, what was Sun thinking?

Logging is an invaluable tool in tracking the usage and finding bugs in a site. I've never found Log4J to hinder performance and I find that logging is an excellent complement to test-driven development with JUnit.

If you've read this far with any interest, I'm sure you've heard of JUnit. JUnit is the very simple software behind test-driven development in Java. Basically instead of just writing your program, you write the test first. For example, say I want to write a class that handles the user data in the database. I would follow the following steps:

1. Create a class called UserDAOTest that extends TestCase from the JUnit package.
2. Write a test case that does what you want it to do.

   public void testValidateUser() throws Exception {
  try {
    Integer userKey = userDAO.find("testUser");
    userDAO.remove(userKey.intValue());
  } catch ( DAONotFoundException e ) {
    Category.getInstance(UserTestDAO.class).warn("Did not find test user");
  }
  Integer key = userDAO.create(new User("testUser", "helloWorld"));
  User user = userDAO.load(key.intValue());
  assertEquals("testUser", user.getUsername());
  // Always encrypt passwords
  assertEquals("PsncrsDzen0YY", user.getPassword());
}


3. Now implement the code to make that test succeed.

Unit testing database entity handlers like a user row is fairly strait forward. However, the front end web environment is based on a the struts of the Servlet definition. Since this is a unit test environment, I would like to be able to test without running an instance of Tomcat. The MockStrutsTestCase does that rather nicely and you follow the same process as descibed above.

I haven't found much use in the unit testing area for HttpUnit, because the struts mock objects will tell me what I need to know about the processing of http requests. What it won't tell me is how those Http requests work on a real web system running under Tomcat. HttpUnit requires me to have a running site and will let me run automated tests on that site. I like to use it for stress testing or for finding threading and other kinds of problems.

The value of HttpUnit is that it doesn't do unit testing at all. It lets me step outside the system and test the actual use of the product. In the XP vernacular - acceptance testing. At this level, I look for some simple marker in the page and pass tests based on that marker. Mostly what I look for with HttpUnit is errors in the logs.