## What's New in 3.6 (JDT)

Here are descriptions of some of the more interesting or significant changes made to the Java development tools for the 3.6 release of Eclipse. They are grouped into:

- Java Editor
- Java Formatter
- Java Refactorings
- Java Compiler
- Java Views and Dialogs
- JUnit

See also the Eclipse Platform What's New in 3.6 document for changes in the Platform.

Java Editor
Fix multiple problems via problem hover | The problem hover now shows quick fix links that fix multiple instances of a problem in a file: The new links behave the same as pressing Ctrl+Enter in the Quick Fix proposal list (Ctrl+1).
Javadoc hovers include annotations | Javadoc hovers now include annotations:
Javadoc hovers render {@value} | Javadoc hovers now render {@value} inlined:

Command to open an implementation

The Open Implementation command is available from the Navigate menu. A key binding can be assigned on the General > Keys preference page.

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.

Improved content assist for getter and setter proposals | Content assist now proposes all possible getter and setter proposals in case of field name clashes and no longer proposes setter proposals for final fields.
New 'Java Code Style Preferences' category when importing or exporting preferences | When importing or exporting preferences, a new category is available that allows you to control whether Java code style preferences are imported or exported:
Java Formatter
Control the formatting in code sections | This preference allows you to define one tag to disable and one tag to enable the formatter (see the Off/On Tags tab in your formatter profile): Here is an example of formatted code which is using code sections with the tags defined as shown above:

New strategy to wrap nested method calls

The Java formatter now tries to wrap the outermost method calls first to have a better output when wrapping nested method calls.

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.

Insert a new line after a label | For example, with this preference activated as shown above, the loop will be placed on a new line after its label:
Align element-value pairs in annotations | 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:
Wrap method declaration | 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:
Put start and end of comments on separate lines | This preference lets you to decide whether the beginning and the ending characters of a multi-line comment will be placed on separate lines or not: For example with the above preferences disabled, a block comment can be formatted to take less lines in the code:
Skip formatting of line comments starting at first column | This preference lets you decide whether line comments which start at the first column of the file will be formatted or not: For example, with this preference not activated as shown above, the first comment is untouched after the formatting:
Java Refactorings

Extract Method improvements

The Extract Method refactoring now handles selections that contain `continue` statements. To preserve the semantics of the existing code, the selection needs to include the last statement of the loop. In the extracted method, `continue` statements are changed to `return`:

For a selection that would need multiple return values in the extracted method, Eclipse now lists the conflicting variables in the error message:

Move type to new file refactoring | The Convert Member Type to Top Level refactoring has been renamed to Move Type to New File and now allows any secondary type in a file to be moved into its own file. The action continues to work for member types.
Java Compiler

Report missing `@Override` for method implementations in 1.6 mode

The compiler now reports about missing `@Override` annotation in the case where a method implements a method from an interface:

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.

New "rawtypes" token for `@SuppressWarnings` annotation | The compiler now makes the distinction between warnings reported for raw type usage versus warnings reported for unchecked generic operations. 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.
`@SuppressWarnings` for optional errors | The `@SuppressWarnings` annotation can now also suppress optional compile errors: In this example, Value of local variable is not used 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'.
Compiler detects unused object allocation | The Java compiler can now detect unused object allocations: This detection is disabled by default and can be enabled on the Java > Compiler > Errors/Warnings preference page at the end of the Potential programming problems section.
Import and export compiler preferences | The new 'Java Compiler Preferences' category allows to just import or export the compiler preferences:
Java Views and Dialogs

New build path error decorator

Build path problems are sometimes easy to miss among other problems in a project. The Package Explorer and Project Explorer views now show a new decorator on Java projects and working sets that contain build path errors:

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:

Package name abbreviations

Package names in Java views can now be abbreviated with custom rules. For example, the following rules produce the rendering shown below:

    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.

Remove nodes from Call Hierarchy | The Call Hierarchy now allows to remove a single or multiple nodes from the view via context menu:
Improved refresh in the Call Hierarchy | The Call Hierarchy now allows to refresh single or multiple elements at once via the Refresh (F5) action from the context menu: 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.
Type Hierarchy computed in background | The Type Hierarchy is now computed in an operation that can be sent to the background (or always runs in the background, depending on your settings): Your workbench is no longer blocked while a big hierarchy is computed.
Export all profiles | The Formatter preference page and the Clean Up preference page now have an Export All... button that allows exporting all user-defined profiles into an XML file. The exported profiles can be imported from the XML file at once using the Import... button.
Opening attached Javadoc now uses preferred web browser | Open External Javadoc has been renamed to Open Attached Javadoc and now uses the configured web browser:

Instance counts

The Variables view provides a new column displaying the number of instances corresponding to the concrete type of each variable. To display the column, select Layout > Select Columns... from the view's menu, and then select Instance Count from the Select Columns dialog. Note that instance counts are only available debugging on JavaSE-1.6 (or newer) and are not applicable to primitive types.

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.

Java breakpoint detail | The Java breakpoint detail panes now display all properties in a single pane. Detail pane orientation can be configured via the Layout view menu. 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.
Source attachments for referenced JARs | Source attachments can now be configured separately for JARs that are not directly on the classpath of a Java project, but referenced from another JAR via the `Class-Path:` attribute in the `MANIFEST.MF`:

Find broken externalized strings improvements

Source > Find Broken Externalized Strings now reports less false positives:

• 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:

New Java appearance category when importing or exporting preferences | There is a new category available when importing or exporting preferences that allows you to control whether Java > Appearance preferences are imported or exported:
JUnit
JUnit 4.8.1 | The JUnit 4 version shipped with Eclipse has been updated to 4.8.1.

2 versions of org.junit plug-in

The SDK now ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1). Clients that want to run JUnit Plug-in Tests with a Java 5 or later VM and that require org.junit with a version bound that does not include 4.x need to update their version bound to include 4.x (e.g. by specifying `Require-Bundle: org.junit;bundle-version="3.8.2"`. If they don't update their bounds, both versions of org.junit are resolved at run time, which leads to errors when test classes are loaded.

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.

JUnit view opens test result URL

The JUnit view can now directly load test result files from an URL. You can either just drag and drop an URL to the view or open the Test Run History... tool bar button's drop-down and choose Import from URL... to enter an URL from which the test results should be loaded.

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

JUnit imports test results with `<skipped>` nodes | The JUnit view can now import test run files that contain `<skipped>` nodes. Eclipse and the Ant JUnit task do not generate such nodes, but e.g. test result files from Apache Maven do generate them for ignored JUnit4 tests.
Edit test method in JUnit launch configuration | In JUnit launch configurations, you can now edit the test method: When the test method is empty, all tests in the class will be run.
org.eclipse.jdt.junit split | The non-UI parts of the `org.eclipse.jdt.junit` plug-in have been split off into the new plug-in called `org.eclipse.jdt.junit.core`. This change does not affect existing clients of the `org.eclipse.jdt.junit` plug-in, but allows new clients to use only the launcher without requiring all the UI dependencies.