Some years ago I did all my coding in vi, then later in Emacs. I still believe these are great editors; I just don't use them anymore for Java development, especially J2EE application development. I'm much more productive if I use an IDE whose sole purpose in life is to facilitate product development. I can probably still write code faster if I use vi. However, I doubt I could meet my deadlines if all I had was a tool that was primarily meant to be an editor. Emacs is a great environment for setting up and using a development environment. However, it is for all purposes a code editor, not an IDE.
Developing distributed applications is a complex process, and developing the components that make up the application requires coordination and integration of different design and development environments. The software development cycle for the release of a product warrants the use of data and component modeling tools; sophisticated code editors; a fully integrated compilation and build environment; deployment tools; fully integrated debugger, unit, and integration testing environments; and source code version control. Nowadays, you have two options when developing J2EE software. One, use your skills to create a development environment that can use tools from different vendors cohesively and effectively. Two, buy something that provides this environment out of the box.
Which option would you prefer? If you're the only one developing the modules, you may have the luxury to go with the first option. However, if you're involved in the development of J2EE applications, you're much better off with a true integrated development environment that allows you to develop components autonomously, unit test them, test them in your application framework via integration testing, and deploy them into your runtime environment. That way you can easily share your development efforts with your team.
In addition, several IDEs offer refactoring capabilities that will allow you to modify component design after the code has been developed. Several IDEs in the market offer a large part of this functionality out of the box. I've worked with Borland's JBuilder and IntelliJ's IDEA. Both are excellent IDEs that support the development features mentioned earlier, including deployment to the main J2EE application servers, unit testing using JUnit, support for refactoring, and integration with source control systems. There are several other J2EE IDEs to choose from (e.g., WebGain's VisualCafé). Usually application server vendors' tools don't have the level of sophistication offered by J2EE IDEs.
Of course, cost becomes a factor. Some of these IDEs are fairly expensive and buying enterprise licenses can be a costly proposition. However, for large enterprise projects, the benefits accrued by saving precious development hours will be well worth the cost.
What role will the popular editors like Emacs and vi have in J2EE development? Well, some of the IDE vendors are incorporating these into their tools. For example, Java Development Environment for Emacs (JDEE) is a software package that interfaces Emacs to command-line Java development tools (e.g., JavaSoft's JDK). Similarly, TogetherSoft is incorporating vi and Emacs into their tools offerings.
Speaking of development tools, one of the requirements for any successful J2EE project is the right references - online and printed material that gets you the background information you need to get up to speed and hit the ground running. Recently, I came across a new style of books that has proved very useful in developing J2EE software. They're printed as a suite of "CodeNotes" from Infusion Development Corporation - guidelines from developers who have obviously spent some time in the trenches. I've looked at the J2EE and XML CodeNotes, and these are definitely handy references to keep at your desktop.
Ajit Sagar is the J2EE editor of JDJ and the founding editor of XML-Journal. A lead architect with Metavonni, LC,
based in Dallas, he's well versed in Java, Web, and XML technologies.