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:
See also the Eclipse Platform What's New in 3.6 document for changes in the Platform.
Java Editor |
|
New 'Java Code Style Preferences' category when importing or exporting preferences |
There is a new category available when importing or exporting preferences that
allows you to control whether Java code style preferences are imported or exported.
|
Javadoc hovers include annotations |
Javadoc hovers now include annotations:
|
Javadoc hovers render {@value} |
Javadoc hovers now render {@value} inlined:
|
Java Formatter |
|
Formatter profiles can be configured on the Java > Code Style > Formatter preference page. | |
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: |
Align method declaration |
![]() For example, the modifier, the return type and the name of the method can be each one 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: |
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 a formatted code which is using code sections with the tags defined as shown above: |
New strategy to wrap nested method calls |
This preferences allows you to disable the new strategy when wrapping
nested method calls:
Now, the Java formatter 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 calls are kept on a single line: Note that this preference is checked by default (i.e. the new behavior is automatically activated). If the backward compatibility regarding previous versions' formatter behavior (i.e. before 3.6 version) is necessary, then this preference has to be unchecked in order to get the previous formatter behavior back. Note also that the new strategy currently only applies to nested method calls, but that might be extended to other nested expressions in future versions |
Put comments start and end on separated 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 these preferences not activated as shown above, 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 Compare Editor |
|
Java Refactoring and Source Actions |
|
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 :
|
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 |
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 |
@SuppressWarnings for optional errors |
The @SuppressWarnings annotation can now also suppress optional compile errors:
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'. |
Compiler detects unused object allocation |
The Java compiler can now detect unused object allocations:
|
Java Views and Dialogs |
|
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. |
Remove nodes from Call Hierarchy |
The Call Hierarchy now allows to remove a single or multiple nodes from the view via context menu:
|
New Open Implementation command |
The Open Implementation action is now 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. |
Export All... from Formatter preference page |
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.
|
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.
|
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.
|
2 versions of org.junit plug-in |
The SDK now ships 2 org.junit plug-ins (versions 3.8.2 and 4.7.0). 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.
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: |
Edit test method in JUnit launch configuration |
In JUnit launch configurations, you can now edit the test method:
|
New categories when importing or exporting preferences |
There are two new categories available when importing or exporting preferences. The
wizard now supports importing or exporting Java compiler settings and JDT appearance
preferences.
|
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. |
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 4.7 | The JUnit4 version shipped with Eclipse has been updated to 4.7. |
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:
|
'Find Broken Externalized Strings' handles constants | Source > Find Broken Externalized Strings can now handle constants used as message keys
(in addition to directly embedded string literals).
In the example below, MAIN_INDIRECT is no longer listed as an undefined key.
|
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, since 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.
|
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:
Rules for this example: org.eclipse.ui={UI} org.eclipse.ui.texteditor={T} org.eclipse.ui.internal.texteditor=[iT] The abbreviation rules can be configured in Preferences > Java > Appearance > Abbreviate package names. |