This action is enabled on text selections in the Java editor for overridable methods and directly opens the implementation in case there's only one, or shows all the concrete implementations for that method in the hierarchy of its declaring type, using the Quick Type Hierarchy.

Here is an example of formatted code which is using code sections with the tags defined as shown above:

Here is an example of a formatted code where the formatter has wrapped the line earlier, e.g. between the arguments of the outermost message call. Doing this, each nested method call is kept on a single line:

A new preference allows you to disable this new strategy, e.g. if you want to format your code as before:

Note: Currently the new strategy only applies to nested method calls, but that might be extended to other nested expressions in future versions.

For example, with this preference activated as shown above, the loop will be placed on a new line after its label:

For example, the two annotation arguments are each put on a new line if the chosen alignment policy for this preference is Wrap all elements, every element on a new line and if the Force split check-box is selected:

For example, the modifier, the return type and the name of the method can each be placed on a new line if the chosen alignment policy for this preference is Wrap all elements, every element on a new line and if the Force split check-box is selected:

For example with the above preferences disabled, a block comment can be formatted to take less lines in the code:

For example, with this preference not activated as shown above, the first comment is untouched after the formatting:

This new behavior can be controlled via Java > Compiler > Errors/Warnings in the Annotations section and configured for Clean Up and Save Actions.

Note: This is reported only in 1.6 mode as @Override annotations are not expected on a method implementation in 1.5.

In case it is not possible to update the code with the new token, the suppressRawWhenUnchecked=true system property can be set when starting Eclipse.

In this example, Local variable is never read has been set to Error.

This behavior can be enabled on the Java > Compiler > Errors/Warnings preference page in the Annotations section with the check box Suppress optional errors with '@SuppressWarnings'.

The concrete errors can be seen in the Problems view, and if you open the view menu and select Group By > Java Problem Type, they all show up in the Build Path category:

org.eclipse.ui={UI}
org.eclipse.ui.texteditor={T}
org.eclipse.ui.internal.texteditor=[iT]

Without abbreviations:	With abbreviations:

The abbreviation rules can be configured on the Java > Appearance preference page.

This will refresh the selected elements and their direct children. The action in the toolbar has been renamed to Refresh View and still refreshes the entire view.

Your workbench is no longer blocked while a big hierarchy is computed.

You can also display the instance count of a selected type in an editor or editor outline and selecting Instance Count... from the context menu. The result is displayed in a dialog.

For example, a Java line breakpoint allows its condition to be edited in place with content assist. Use the File > Save (Ctrl+S) action to save a condition that has been edited. Radio button properties are saved immediately.

• It ignores all methods that don't take a single parameter of type String. For example, method calls like Messages.getResourceBundle() are no longer listed as undefined keys.

• Constants used for message keys are now correctly recognized. In the example below, MAIN_INDIRECT is no longer listed as an undefined key:

For complete details on the steps required to transition to using JUnit4 or to continue using JUnit3, please see:
http://wiki.eclipse.org/Eclipse/Testing/JUnit4_Changes.

Supported test run formats are XML files exported from the JUnit view or generated by the Ant JUnit task.