The Ideal Integrated Development Environment (IIDE)
My Ideal IDE consists of a number of small tools that work well together.
The Editor and Grep (Find-in-Files)The programmer's editor occupies the center of the IIDE. A good editor has syntax coloring, auto-indent, a macro language, and a customizable tools menu. It should also have a built in grep-like search capability. I use WinEdit, which has most of the items on my fairly extensive list of Essential Programmer's Editor Features.
Source Control and the CompilerThe other two essential tools are source control and, of course, the compiler. I don't care for "integrated" source control, so either SourceSafe or CVS, GUI or command line, works fine for me. Good history reports and version diffing help in the exploration and debugging efforts. The editor should be able to fire up the compiler (F7 in my case) in order to make the edit-compile-test-edit cycle as short as possible.
The DebuggerSome programmers need debuggers more than others. Myself, I get along fine without one. But if I absolutely must have it, I'll use jdb from the command line. Crude but effective. There's a good chapter on using jdb in Advanced Programming for the Java 2 Platform by Calvin Austin and Monica Pawlan. You'll find the chapter on-line at Sun's Java Developer Connection.
Four other tools facilitate inter-group communication and design.
The Text DocumenterEvery project needs design and requirements documents. The industry standard seems to be Microsoft Word, but frankly, it stinks. I prefer HTML. It's more portable, and better, it has fewer formatting options, so you'll spend less time making things look cute and more time making them sound right. Substance beats style every time, unless you work in Marketing.
You don't need an authoring tool to write simple documentation in HTML. A text editor will work fine. Learn the minimum HTML you need to know. For greater clarity, consider translating your documents into E-Prime, a sub-dialect of English.
The API DocumenterFor API Documentation, learn to use javadoc. Read How to Write Doc Comments for Javadoc and study the javadoc documentation. Require your programmers to complete their documentation, and write up problem reports when you find incomplete or inaccurate documentation. (This assumes you have a bug-tracking system, which I don't include in my Ideal IDE because, ideally, you won't need it.)
The DiagrammerA picture (well drawn) is worth a thousand words (well written). More important even than improving inter-team communication, good diagrams will lead you to improve your design. Unfortunately, I haven't found any decent tools yet. If modern IDEs (Borland and Symantec) require a level of commitment akin to marriage, modern CASE tools require a level of commitment nearer to joining a monastery. I want a cheap, easy tool for diagramming, with minimal reverse-engineering capability, and JPEG, PNG, or GIF output. Visio used to work, before it got bloated. Now I'd rather use StarOffice, free from Sun.
The FormatterFinally, unless you program all alone, you'll see a lot of ugly code. To make it less ugly, you need a formatter. Jindent fits the bill. You can require your programmers to follow the Java Code Conventions, and then, if they don't, run their code through the formatter. Personally, I'd rather make enemies than look at ugly code.
Other Essential ToolsYou'll need the Java SDK and its documentation, and Netscape to view that documentation. You'll also want a well stocked bookshelf, plenty of browser bookmarks, e-mail, a good project manager, a high rate of pay, a coffee maker, and either a cafeteria or a doting mother (Mom's better).
In time, probably before you retire, you'll figure out what you're doing.