What's New in Eclipse 3.2 Java Development Toolsby Ed Burnette
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).
The Making of 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.
The Eclipse Compiler
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: A compiler may not harm a source program.
- Efficiency: A compiler must be fast, except where speed would conflict with the first law.
- Friendliness: A compiler must assist the user to correct programming errors, as long as such assistance does not conflict with the first and second laws.
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:
- Using variables that are obviously
- Unnecessary checks against
- Accidentally assigning to method parameters.
- Switch cases entered by falling through previous cases.
- Using non-generic (raw) types.
- Unused labels.
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.