In some IDEs, you set one project to be the "main project" and use a global Run command to run the program. Eclipse doesn't work that way. In Eclipse, you have a list of launch configurations, which contain all the details necessary to run or debug or test the code, such as command-line parameters, class paths, JRE versions, and so forth. Eclipse 3.2 makes it easier to manage the launch configurations through the use of filtering and execution environments.
Filtering lets you cut down on the configurations listed to be just the ones in which you're interested. Execution environments let you describe the capabilities of a Java runtime using a generic name like "J2SE-1.4." Eclipse will pick the JRE that meets or exceeds the requirements of the environment you specify.
Do you find yourself running more than one test suite during development? In 3.2 you can have multiple suites running at the same time, and you can go back and look at the history of previous runs. Eclipse 3.2 also supports the latest version of JUnit, version 4.0.
Working in a Team
Do you ever find yourself staring at a line of code, wondering who put that in and why? Eclipse 3.2 can show color-based annotations of who did what in the current file by reading the CVS history (see Figure 3). Hovering over a change block will show the developer name, date, and comments that were entered for that change. It will also highlight other sections of code in the rest of the file that were contributed in the same revision.
Figure 3. CVS Quick Diff annotations show color-based annotations of who did what in the file. Hovering over a section shows the details of that revision.
I'm sure you've had this experience: you're calling somebody else's code, and everything is working until they come out with a new version. Then you start getting deprecation warnings, or worse yet, compiler errors, until you modify your program to conform to their changes. Well, Eclipse 3.2 has a cool new feature called "refactoring scripts" that can make this much less painful.
Refactoring, of course, simply means making changes to source code without changing its behavior. For example, maybe there was a field that was misspelled, or a method needed a new parameter. Eclipse has always had good support for automating these changes if you were the developer of the code being changed. And now it provides help for the consumers, too.
Every refactoring operation you do is recorded in a history. Eclipse 3.2 lets you write that history out into a script file, and then play it back later. You can save the script in CVS or include it in a JAR file so users of the JAR can play back the same changes when they get a new version. This is different than applying a patch or diff. Patches only operate on the specific source files for which they were created. Refactoring scripts can operate on any arbitrary source file that uses the refactored API.
Maintaining a growing an API for others to use is hard work, and now Eclipse makes it easier. When you rename a method, Eclipse 3.2 will offer to leave the old method there, mark it deprecated, redirect it to call the new method, and make a refactoring script to automatically convert all callers when they import your new JAR file.
Eclipse has long had a very powerful code formatter to help you apply code formatting standards across an entire team. Version 3.2 takes this a step further with a new Clean Up wizard (see figure 4). Here are just a few things this wizard can optionally do:
- Remove unused imports.
- Remove unused private methods and constructors.
- Add missing
- Add missing
$NON-NLS$tags, or remove unnecessary ones.
- Convert all
forloops to be enhanced-
- Convert control statement bodies to blocks.
- Remove unnecessary casts.
- Add serial version ID to
The Clean Up wizard can be run over one Java file, a package, or a whole project.
Java programmers have a wide variety of environments to develop in, more so than any other language or platform. I'm not sure why that is--perhaps it's a result of the energy and enthusiasm of the users, or perhaps it's a result of the lack of a single dominating vendor like Microsoft imposing its will and tying their tools directly to the platform. Whatever the reason, Eclipse competes with many alternatives, including NetBeans, IDEA, JDeveloper, and JBuilder. With release 3.2, Eclipse has raised the bar once again on Java IDEs, which will benefit all Java programmers, regardless of which tool you ultimately choose.
Ed Burnette is a professional developer and author living in Cary, North Carolina.
Return to ONJava.com.