Eclipse Ganymede: An in-depth look at JDT (Java Development Tools)

Posted by Alex Blewitt and Ryan Slobojan on Jun 24, 2008

Sections

Development

Topics

Java

Tags

Eclipse

As part of the upcoming Eclipse Ganymede release, scheduled for June 25th, InfoQ will cover a series of Eclipse subprojects. Today, the subproject is JDT (Java Development Tools), which is releasing version 3.4. InfoQ spoke with Philippe Mulet, lead of the Eclipse project, and Martin Aeschlimann, lead of the JDT UI subproject, to learn more about what to expect in Ganymede.

There are several new features in JDT 3.4:

• Compiler enhancements - Compilation can now be spread across multiple cores rather than being able to only utilize one, compiler problem detection has been improved, CLDC 1.1 class file output support and class folders outside of the workspace have been added
• New refactorings - There is a new Extract Class refactoring, which extracts a group of variables into a class and preserves member access. In addition, refactoring that causes potentially broken references to binary classes will now show a warning, which can be used to prevent accidental refactoring that other clients might rely on
• Java Editor upgrades - Breadcrumbs which show the path to the current item, richer hover dialogs for Java problems and Javadoc, several Content Assist improvements, new Quick Assists and a set SWT widget templates are among the new features added
• Java Debugger improvements - Object inspector embedded in the variable hover, execution environment description files, launch configurations as part of search results and the ability to wait for remote debug connections are new in this release
• Other UI enhancements - JUnit test execution time, Call Hierarchy for fields and types, a Runnable JAR export wizard, and more Java search options are now available

Full details will be available on the New and Noteworthy page shortly after the official Ganymede release on June 25th.

Mulet explained the multicore compilation in more detail, saying that although each project is compiled individually, the ability to spread the compilation load of the project across multiple cores results in speed increases of between 10% and 30% on multicore CPUs. Mulet was also careful to note that these percentages are provisional, and that public benchmarking data would be published in the near future. Another note is that the greatest speed increases came with newer versions of Java - Java 1.4 tended to have a speed increase closer to 10%, and Java 6 had speed increases closer to 30%. Finally, a critical factor in compilation performance is the disk speed - since compilation is an inherently I/O-bound process, having faster media results in much faster compilation times.

Although Eclipse is mainly known as a Java IDE, many of the improvements led by the JDT and JDT UI teams have been pushed down into generic libraries such as the Language Toolkit (LTK) and Platform Text, which are used by other text-based editors such as CDT to provide generic refactoring, search, debug and compare functionality. For example, these libraries have been used to provide the rich Javadoc hover text, which allows links to be followed. One potential future enhancement which may be targeted for 3.5 is preprocessing support, which will simplify integration for a range of uses according to Mulet.

The Eclipse Compiler for Java (ECJ) is another component which has been adopted outside of JDT, and Mulet said that projects that he knew of which use ECJ include the GNU Compiler for Java (GCJ), Apache Harmony's javac, the Apache Tomcat JSP, and the AspectJ compilers. Mulet added that he believes this is only a partial list, and that he would be very interested in learning who else is using ECJ as part of their work.

With respect to future plans, Mulet said:

We are starting to think about it right now; suggestions are welcome. Possible topics (no commitment) could be to look at Java 7, Java editor nesting, preprocessing, settings/classpath per source folders, better integration with API tooling, chained JARs on the buildpath, nested JARs on the buildpath, provide compiler error explanations, simplify out-of-the box experience (e.g. compliance and JRE should be paired by default) etc...

When asked how JDT would be integrated into or affected by e4, Mulet said:

e4 is about making Eclipse a better platform, simpler to build upon. Once e4 is advanced enough, JDT will likely rehost on it, similar to how it all started on Eclipse 1.0. It will be interesting to evolve 2 flavors of JDT after that point, since 3.x is not going to disappear immediately, and JDT in 3.x will have to stay current with Java there as well... until then JDT is likely going to help near cross-compilation from Java to scripting languages (like it does today for translating some Java into ActionScript). There could also be some more initiatives near language tooling, think of multi-language editors for instance.

• Older >