This document contains descriptions of some of the more interesting or significant changes made to the Java development tools for the 3.2 release of Eclipse. It is broken into several sections:
Java developers will also be interested in the corresponding What's new document in the Workbench User Guide.
General Java Tools |
|
Create and apply refactoring scripts |
Refactorings executed in one workspace can now be exported and reapplied in other workspaces. This feature allows you, for example, to make changes to API classes using refactorings (i.e. rename a type) and ship this changes to your clients. Your clients can then reapply the refactorings in there workspaces to prevent API incompatibilities. Create a script from the refactoring history using Refactor > Create Script... To apply the generated script on an arbitrary workspace use Refactor > Apply Script... |
JAR file export with refactorings |
You can now include refactoring information into a JAR file during a JAR export. Use the JAR Export Wizard to export your code together with refactoring information. Access this wizard through File > Export... and select the refactorings to export on the first page of the wizard. Your clients can update there workspaces by using Refactor > Migrate JAR File.... This will automatically offer to replay the stored refactoring on the source files in the project. |
Refactoring History |
A Refactoring History stores the information about refactorings executed in your workspace. You can access and modify this history through Refactor > History... |
JUnit 4 support |
Eclipse supports the new JUnit 4 and its improvements. You can write JUnit 4 tests or use the New JUnit Test Case Wizard to generate the tests. For instance:
|
JUnit view history |
The JUnit view can now handle multiple concurrent test runs. You can switch between active and recent test runs through the new history. You can rerun tests from the history or rerun a single failed test without stopping already running tests. This works with JUnit 3 as well as with JUnit 4. |
Clean Up Wizard |
The Clean Up Wizard helps fixing multiple problems at once and to establish a code style. For instance, you can:
The wizard is especially helpful when converting Java 1.4 compatible code to Java 5.0. Select a project, package, or file and use Source > Clean Up... to start this wizard. |
Extract Superclass refactoring |
A brand new refactoring called Extract Superclass extracts a common superclass from a set of sibling types. The selected sibling types become direct subclasses of the extracted superclass after applying the refactoring. Moreover, Extract Superclass allows to use the extracted superclass wherever possible in the code. The next picture shows the type hierarchy after extracting To invoke this refactoring use Refactor > Extract Superclass.... |
Introduce Indirection refactoring |
Another new refactoring is Introduce Indirection. It lets you redirect all callers of a method to a new method. The new method calls the original one. You can replace the default implementation of the new method by any other if you like. Such an indirection is useful when new behavior needs to be introduced to a method but:
Use the indirection for bug fixes to the original method or as a quick way to add code before or after all calls to a method. To execute the Introduce Indirection refactoring select a method, invoke Refactor > Introduce Indirection..., provide a name and the declaring class for the new method. The method is added to the selected declaring class. And all references are updated to call the new method. |
Rename Type updates similarly named elements |
The Rename Type refactoring can now rename variables and methods with names similar to the renamed type. This feature helps to keep method and variable names synchronized with type names. To invoke this refactoring select a type and use Refactor > Rename... |
Category support |
Categories are a new Java 6.0 feature. Categories
can be defined in Javadoc comments for types, methods, and fields using
the Categories are shown in the Outline view, the Quick Outline, and the Members view in the Java Browsing perspective. Also available is a filter to specify which Categories should be shown. All these features are available independent of the compiler compliance level. |
API aware refactorings |
There are a number of existing refactorings which have been extended to support API compatibility by keeping the original member as a delegate to the refactored member:
The generation of a delegate member to preserve API compatibility can be enabled by checking Keep original method as delegate to renamed method in the refactoring dialog. |
Rename Package refactoring renames subpackages |
The Rename Package refactoring does now also rename subpackages on request. In this example, To invoke this refactoring select a package and use Refactor > Rename... |
Find Broken Externalized Strings |
A new action can search for broken externalized strings. The search reports missing keys, unused keys, and duplicate keys. To start the search select a properties file, a package, or a whole project and use Source > Find Broken Externalized Strings |
Generate hashCode() and equals() |
A new action can be used to generate the methods
To invoke this action select a type and use Source > Generate hashCode() and equals()... |
"Surround With" quick menu |
A new quick menu allows to surround a selection of lines with code. The menu is extendable with custom templates. The templates are now aware of variables that need to be pulled out or made final. To show the menu select a line and use Source > Surround With You can add your custom templates on the Java > Editor >
Templates preference page. All the template needs is a |
Paste type declaration creates new compilation unit |
Importing and running a Java snippet from an e-mail or bugzilla has never been easier:
A new Java compilation unit is created with the given source, and the Java editor is opened on it. When pasting into a package, the package declaration is added/updated to match the location. When pasting directly into a source folder, the package declaration in the copied source defines where the new compilation unit should get created. |
File content decorator |
Enable the Java Type Indicator on the General > Appearance > Label Decoration preference page to find out what the first type in a compilation unit or class file is. |
Filter for refactoring preview dialog |
The refactoring preview page now supports filtering of changes. This is especially helpful when updating textual matches in comments and strings is requested while renaming Java elements. The screen shot shows the rename dialog filtered for textual matches
while renaming the class Changes related to the visibility of Java elements can now be filtered as well. |
Command line code formatter |
It is now possible to format source code without starting the Eclipse UI using the new headless formatter application. The command line formatter works as a standard Eclipse application. The following command will format the source files in the folder src with the options specified in the config.prefs file: See Help > Java Development User Guide > Tasks > Using the Formatter Application for details. |
Support for Java-like extensions |
Files with a file extension other than .java and containing pure Java code are now supported. A Java-like extension can be added using the General > Content Types > Text > Java Source File preference. |
New Quick Fixes |
Several new quick fixes have been added, for example:
|
Java Editor |
|
Customizable Content Assist |
Repeatedly invoking content assist (Ctrl+Space on most platforms) now cycles through different proposal categories. You can assign separate key shortcuts to your favorite proposal categories and configure which should be shown in the default content assist popup. Configure content assist on the Java > Editor > Content Assist > Advanced preference page. A new extension point allows plug-in writers to contribute completion
proposals and categories to the content assist process of the Java editor.
See the |
CamelCase support in code completion |
Code completion now supports CamelCase patterns. For example, completing on NPE will propose NullPointerException. This support can be enabled or disabled using the Java > Editor > Content Assist > Show camel case matches preference. |
Ruler support and outline for Java files outside workspace |
The Java editor now shows vertical rulers and the Outline page as well as the Quick Outline shows the outline for external Java files and Java files from repositories. |
All members can be folded |
When projection is enabled, fields and initializers and their comments can now be folded away the same way as methods. There are new text folding commands for collapsing all comments, collapsing all members, and resetting the folding structure. These commands are found on the Java editor's Folding context menu on the vertical ruler. |
Improved support for Eclipse's string externalization mechanism |
Eclipse string externalization mechanism has now the same kind of support as traditional string externalization. The associated externalized value is shown in a hover, when you linger over a key for an externalized string in the Java editor. Ctrl+Click on the key to navigate directly to the entry in the corresponding properties file. In the properties file editor you can use Ctrl+Click to find out where the key is used in the code. |
Javadoc view and tool tips from attached Javadoc |
The Javadoc view and the Javadoc hovers now extract the information from the attached Javadoc for libraries that do not have source attached. |
Completion in Javadoc comments |
Completion is now available in Javadoc comments. The proposals include both: an "@link" proposal and a regular reference proposal. |
Java Compiler |
|
Java SE 6.0 compliance |
The Java SE 6.0 compliance is now fully supported.
In particular, |
Null reference analysis |
The Java compiler is now capable to perform basic null reference analysis for local variables. This optional diagnosis can be enabled using the Java > Compiler > Errors/Warnings > Potential programming problems > Null reference preference. Note that the analysis is fairly conservative, aligned on definite assignment rules. It only considers cases where there is something suspicious (e.g., if later on a null check is performed), rather than complaining on all possible cases. In 5.0 compliance mode, null reference warnings can be silenced using
|
Improved syntax recovery |
The internal Java parser is now much more resilient to syntax errors. In Eclipse 3.1, a syntax error would prevent subsequent errors from being displayed. The parser can now recover from statements with errors and go on to perform further analyzes. In the following example, the invalid reference to method This for example allows refactorings that only affect a single file to tolerate syntax errors. For instance, it is now possible to rename or extract a local variable at the top of a method that has not yet been written completely. |
Treat configurable Errors as non fatal |
The option Java > Compiler > Building > Treat configurable errors as fatal errors controls if a configurable error is intended to be fatal or not. This option is enabled by default. If this option is disabled then the compiled code can be executed despite the fact that errors exist in the code. |
Detection of unnecessary $NON-NLS$ tags |
Unnecessary The reporting can be turned on and off using the same preference as for the detection of non-externalized Strings. It can be set using the Java > Compiler > Errors/Warnings > Code Style > Non-externalized strings (missing/unused $NON-NLS tags) preference. To remove the unnecessary tags use Quick Fix (Ctrl + 1), or Ctrl + 1, Ctrl + Enter to remove all unnecessary tags within a compilation unit. |
Detection of raw type usage |
Usages of raw types are now detected. A raw type is
a reference to some generic type without any type argument (e.g. This optional diagnosis can be enabled independently from unchecked type operations using the Java > Compiler > Errors/Warnings > Generic types > Usage of a raw type preference. This warning can be silenced by @SuppressWarnings("unchecked"). Also a Quick Fix has been implemented to help resolving the raw type usage problem. |
Detection of method parameter assignments |
Assigning to method parameters is considered poor practice. To detect and report such assignments enabled the Java > Compiler > Errors/Warnings > Code style > Parameter assignment preference. |
Detection of unused labels |
The Java compiler now detects unused statement labels. This optional diagnosis can be enabled using the Java > Compiler > Errors/Warnings > Unnecessary code > Unused break/continue label preference. |
Detection of switch case fall through |
The Java compiler can now detect if a case may be entered by falling through a previous case. Empty cases are allowed. This optional diagnosis can be enabled using the Java > Compiler > Errors/Warnings > Potential programming problems > Switch case fall through preference. A quick fix to add a |
Improved performance for large .jar files |
The size limit of the internal Java model cache is now a function of the max heap size (-Xmx VM argument on most JVMs) given to the Java Virtual Machine running the Eclipse IDE. Raising the heap size has a noticeable performance improvement when there are large .jar files on the build classpath. |
Recreating modified .class files |
The Java builder can now recreate modified or removed .class files in the output folder using the original source. This can be controlled using the Java > Compiler > Building > Output folder > Rebuild class files modified by others preference. |
Java Debugger |
|
Execution environments |
An execution environment describes the capabilities of a runtime - for example, J2SE-1.4. You can specify JREs used for running, debugging and building based by referencing an execution environment. The new Execution Environments preference page displays the JREs installed in your workspace compatible with each execution environment. JREs that meet the exact requirements of an execution environment are displayed in bold, and JREs that surpass the requirements of an environment are displayed in the default font. When more than one JRE is compatible with an execution environment, you can select a default JRE to use for that environment by checking it. A build path or launch configuration referencing an execution environment is more portable than one referencing an explicit JRE as a JRE's execution environment can be resolved independent of its name. Use the JRE tab or Edit Library wizard to specify an execution environment for running and building. |
System property launch variable |
A new launch variable allows to dynamically specify system properties as Java program and VM arguments from the Eclipse runtime. The variable accepts a single argument which is the name of the system property to be resolved at launch time. For example, the java.home system property would be referenced with ${system_property:java.home}. |
Evaluation support for arrays |
Evaluation and content assist are now supported for
Java arrays. Use |
Java thread groups |
You can now display thread groups in the Debug View by toggling Show Thread Groups in the view menu. |
Runtime classpath exported entries |
A runtime classpath can be configured to include only exported entries from the build path. By default, a runtime classpath includes all entries (exported and non-exported). From the Classpath tab select the default entry and use the Edit... button to configure the option. |
Suspend Thread versus Suspend VM |
An option has been added to the Java > Debug preference page to control whether newly-created breakpoints suspend a single thread or the entire VM. |