Garibaldi: Have you ever tried one of these?
Miss Cramer: What is it?
Garibaldi: I'm not sure. According to the translator, it's either an aphrodisiac or a floor wax. I can't decide if it's worth the risk or not.
--Babylon 5, "Infection"
Eclipse is a popular Integrated Development Environment (IDE) for Java programming. It can also be used as an environment for other languages like C++ and Ruby, as a framework for consolidating tools of any kind, and as a Rich Client Platform for creating desktop or server applications. The Eclipse open source community is responsible for dozens of projects, ranging from business intelligence to social networking. Eclipse is the name of the non-profit foundation that manages those projects, as well. (And, while I'm pretty sure it's not a floor wax, there is also an Eclipse automobile, a soccer team, and a brand of chewing gum.)
Eclipse version 3.2 forms the cornerstone of the Eclipse Callisto release train: a simultaneous release of ten Eclipse projects on June 30, 2006. This article will focus on the Eclipse IDE, in particular its Java Development Tools (JDT).
JDT's lineage can be traced back to Visual Age for Java (VAJ), written in Smalltalk around 1996. In VAJ, everything was compiled as you typed and fully resolved in memory. This design didn't scale well, was difficult to extend, and made it hard to recreate file artifacts.
In 1999, the IDE team started working on Visual Age Micro Edition (VAME). Written entirely in Java, it used the Standard Widget Toolkit (SWT) for its user interface. VAME was targeted for the embedded space. It used standard Java VMs, and kept the workspace in the file system. However, the files and folder names were unreadable UUIDs.
VAME's incremental compiler was about ten times faster than the one in VAJ. The model was build state-based (as opposed to current Eclipse, which is source-based). VAME had its own repository system called Rapier, and was extensible using plugins.
VAME didn't really catch on in the community, but contained a lot of good ideas that the developers carried to their next project: Eclipse. In 2001, Eclipse 1.0 was released. It was described as "an IDE for anything and nothing in particular." From the beginning, both Eclipse and the JDT were built as a platform for other development tools. The workspace was stored on disk and open to others. Instead of a proprietary repository, Eclipse 1.0 shipped with CVS integration.
Eclipse had one other important difference with its predecessors: it was open source. The user community exploded and became self-sustaining. Most of the new and improved features of Eclipse 3.2 are the direct results of enhancement requests filed by Eclipse users. Over 30,000 requests for fixes and enhancements have been resolved since 3.1. Since it would take too long (and be extremely boring) to go through all of them, we'll just highlight a few that are particularly important for most Java developers.
One of JDT's more powerful features is its built-in incremental Java compiler, which is fully compliant with
javac. Although you can make Eclipse use Ant and
javac, and even have problem markers show up in the IDE (that's new in 3.2), the Eclipse compiler provides better diagnostics and quicker turn-around time.
The JDT compiler was originally written for VAME, and modified for Eclipse. It was built on what the developers call "The Three Rules of Compilation," patterned after Asimov's rules of robotics:
Correctness: When designing a Java compiler, you have to match not only the specs, but the "spirit" of the specs. You don't want to be right alone. So the JDT developers have worked hard over the years to meet the consensus of what the other compilers are doing, including Sun's. Correctness is checked by over 15,000 unit tests in Eclipse 3.2 (compared to zero in VAJ).
Efficiency: Thousands of projects and millions of lines of code is the norm. This has a lot of implications, for example memory consumption has to be predictable and level. Eclipse 3.2 continues to refine this with aggressive optimizations. For example, the developers rewrote a flow graph to use bit operations and it went from 20 percent of the time down to 4 percent.
Friendliness: Reporting errors is an art. A line number is not good enough. Secondary errors are minimized; for example, if you have a missing semicolon in one file, it doesn't impact all the other files that depend upon it. Improved static analysis finds patterns of errors. Eclipse also checks the Javadoc for correctness.
As of release 3.2, the Eclipse compiler is Java-SE-6.0-compliant. That's right, Eclipse supports Java 6 categories and
StackMapTable attributes, even before Java 6 is released. In addition, the compiler has a ton of new diagnostics that will help you discover problems in your code even before you try to run it. VAJ had three diagnostics, compared to the 3.2 compiler, which has 45 diagnostics. Some of the newest ones include detection for:
Most of these are off by default. You can also silence them using the
If you'd like to use the Eclipse compiler outside of Eclipse, starting in 3.2 there is a separate download for that. Its command-line parameters are compatible with
javac, and the download is only about 1MB. Since the Eclipse compiler is open source, a number of other projects, such as Apache Tomcat, bundle it with their software.
The most basic feature of any development environment is the editor. You'll spend most of your time there, so the editor has to be comfortable and unobtrusive, yet powerful. Just about every editor since Emacs has been imbued with at least a rudimentary knowledge of common source languages so that it can provide syntax highlighting. JDT uses its Java model to go way beyond this; for example, it knows the difference between class and instance variables, so it can color them differently. It can even peek inside the source code comments to tell if a method you're calling is obsolete (deprecated) and draw a line through the method call to emphasize that this is a section of code that needs attention.
One of the more useful commands in the Java editor is
Space (content assist). Can't remember what the methods of an object are, or how to spell a class name? Press
Space and Eclipse will offer a list of possibilities that are valid at any given point. Eclipse 3.2 continues to improve this feature. For example, do you find yourself typing long identifiers like "LongJavaName?" Now you can enter "LJN" and press
Space, and Eclipse will know what you mean. This is called CamelCase completion. It works when searching for types, too (
Do you get tired of typing idioms like "
StringBuffer buffer = new StringBuffer();"? Don't repeat yourself. In 3.2 you can type this instead: "
= new ",
();". That's 16 keystrokes instead of 47. Want a different prefix on that variable name? No problem--just start typing it before that second
Space. For example, in 3.2, "
Element root" +
Space is completed to "
Element rootElement" (see Figure 1).
Figure 1. Content assist (
Space) continues to get smarter in 3.2 with its support for CamelCase and keeping already-typed characters
Here's another time saver. In 3.2,
Space will dynamically rearrange its suggestions based on your usage patterns. So, for example, if you always assign
ArrayList instances to
List variables, the
ArrayList proposal will be ranked first so you can pick it more quickly. Code completion even works in Javadocs now, so you can create
@links or regular references without having to remember those long names.
Do you ever find yourself asking, "If the IDE is smart enough to figure out there is a problem on this line, why can't it correct it?" Well, Eclipse has a feature called Quick Fix that does that and more. Put your cursor on a line with a problem and press
1, and Eclipse will offer suggestions to fix it.
Each new release of Eclipse adds new quick fixes; for example, in 3.2, if you're getting a warning about using raw types, put the cursor on that line, press
1, and select a fix like "Add type parameters." Also in 3.2, Quick Fix can take care of many common problems in the same file, or even in multiple files, instead of dealing with each problem individually.
One more feature that I wanted to mention is "rename type." If you're like me, you'll often name your variables and methods similarly to your types. For example if you have a
Bar type, you might have a variable called
fBar and a method called
createBar (see Figure 2). The problem is, if you want to rename
Bar to something else, you've got a bunch of other places that have to be changed, too. Well, 3.2 makes this easier by offering to change variables and methods that have similar names to the type you are changing. This magic renaming is one of my favorite features in 3.2.
Figure 2. When you rename a type in Eclipse 3.2, it offers to rename variables and methods that have similar names
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.
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:
$NON-NLS$tags, or remove unnecessary ones.
forloops to be enhanced-
The Clean Up wizard can be run over one Java file, a package, or a whole project.
Figure 4. The Clean Up wizard lets you apply consistent standards across your entire project (Click for full-size image).
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.
Copyright © 2009 O'Reilly Media, Inc.