Java development tools
|Content Assist highlights matched characters||
The Content Assist popup now highlights the matched characters in proposals.
|Substring code completion||
Content Assist now supports substring patterns. Enter any part of the desired proposal's text, and Content Assist will find it!
For example, completing on
This feature can be disabled using the Show substring matches option on the Java > Editor > Content Assist preference page.
The Java editor now offers default templates for creating "== null" and "!= null" checks.
The Refactor > Rename popup now shows an Options... link which opens
the full Rename dialog that provides more options like renaming a field's getter and setter methods.
The dialog can still be opened via the menu button in the popup or by pressing Alt+Shift+R again. The in-place mode can be disabled entirely via Preferences > Java > Rename in editor without dialog.
Java Views and Commands
|Clean Up to remove redundant type arguments||
A new option to remove redundant type arguments has been added under the "Unnecessary Code" group of the Clean Up profile.
|Create new fields from method parameters||
You can now assign all parameters of a method or constructor to new fields at once using a new Quick Assist (Ctrl+1):
|Search on multi-selections||
You can now select multiple elements in views like Package Explorer and Outline and then search for References, Declarations, Implementors, and Read/Write Access (where applicable):
You can even select results in the Search view and start a new search for those elements. To follow method call chains, you'd probably use Open Call Hierarchy, though.
|Ctrl+Shift+V invokes Open from Clipboard||
Ctrl+Shift+V has been assigned to invoke
Open from Clipboard.
On GTK+ this key binding was previously assigned to the Run > Display command as a workaround for Ctrl+Shift+D not working.
|Adding meta-annotations while creating a new Java annotation type||
You can now choose to add
|Grouping of referenced libraries in Project Explorer||
The Project Explorer view now groups referenced libraries in a new container node.
|Hiding empty library containers in Project Explorer||
You can now hide empty library containers in the Project Explorer view by selecting the new filter in its Customize View... dialog.
|New problem severity level to indicate information||
You can now specify Info as a severity level for the problems detected by the Eclipse Java compiler.
When specified, the information issued by the compiler will be represented as shown here:
|Quick Fix to configure problem severity||
You can now configure the severity of a compiler problem by invoking the new Quick Fix (Ctrl+1) which opens the Java > Compiler > Errors/Warnings
preference page and highlights the configurable problem.
The Quick Fix icon may look familiar to you. In older Eclipse versions, this was a toolbar button in enriched hovers (i.e., you had to press F2 or move the mouse into the hover to see it).
|Multiple sets of null annotations||
You can now configure annotation-based null analysis to use multiple sets of annotation types.
This is relevant if your project uses 3rd party libraries that already use null annotations in their API,
where the annotations used in a library may be different from those used in the current project.
Please open the dialog for configuring null annotation types from the project properties at Java Compiler > Errors/Warnings > Null analysis:
In the dialog that opens, only one primary set of annotations is supported — these are the annotations which JDT actively uses in Quick Fixes, error messages etc. These annotations must be present on the project's build path.
You can now add an arbitrary number of secondary null annotation types, to be evaluated when reading class files external to the project. Within the configuration dialog, Content Assist is offered based on accessible annotation types, but for secondary annotation types unresolved names will be tolerated. This avoids the need to bloat the build path with transitive compile-time dependencies.
|Improved null analysis with generics||
The interplay of null annotations and generics has been improved in several regards.
The basic concepts had already been documented in the online help, but not all that was documented was actually checked by JDT's null analysis. With the changes outlined below, null analysis based on type annotations is even more capable than previous versions.
(1) The first batch of contributed improvements implements what we call "pessimistic analysis for free type variables", which affects implementors of generic types.
In order to allow clients to instantiate such a generic class with either a
At the bottom of each problem hover, you will find a link to the corresponding configuration option, should you like to change the severity of this diagnostic. Note that configurability is mainly given for smooth migration from previous JDT version; conceptually, problems detected by pessimistic analysis should be treated as errors, because they invalidate the null-guarantees given by a generic type.
(2) The second improvement concerns consumption of generic types from a library, more specifically:
invocations of library methods whose return type is given by a free type variable.
The analysis cannot see whether absence of a null annotation for such a return type is intentional (in the above sense of "free type variables"), or an omission that should be fixed. For that reason a new warning has been implemented to alert about this situation.
In the above example, both fields
The dilemma can be resolved by adding a (possibly empty) external annotation file (
In a project that is not yet configured to use external annotations for the library in question, the warning is demoted to level "information". Generally, the severity of this problem is configured using the option right below the one mentioned above, titled Unsafe '@NonNull' interpretation of free type variable from library.
(3) Finally, a small utility class,
|Quick Fix to add @NonNull to local variable||
When a "potential null pointer access" problem is raised against a local variable,
the reason is not always obvious.
Perhaps null is assigned somewhere deep inside a complex control flow.
If annotation-based null analysis is enabled, a new Quick Fix is offered (Ctrl+1),
that adds a
While this may not produce correct code, it tells the compiler your intention to not
|New options in code formatter||
Several new options have been added in the formatter profile editor.
(1) In the Line Wrapping section, you can control the wrapping policy of 'for' loop headers.
(2) The Align fields in columns feature in the Indentation section can now be configured to recognize groups separated by empty lines and align them independently.
(3) In the New lines section, you can control if new lines should be added after annotations on enum constants.
(4) In the new Parentheses tab, you can order the formatter to keep parentheses of various Java elements on separate lines, i.e. put a line break after the opening parenthesis and before the closing parenthesis. This can be done always, only when parentheses are not empty, or when their content is wrapped. There's also an option to preserve existing positions, if you want to manually manage parentheses positions on a case-by-case basis.
(5) In the Line Wrapping tab, you can set the wrapping policy for parameterized types.
(6) Also in the Line Wrapping tab, you can decide to wrap before or after operators in assignments and conditional expressions.
|Installing breakpoints from unrelated projects||
Multiple versions of the same Java type can be available in a workspace, and each version can
have breakpoints configured at different source locations. When debugging, JDT tries to
determine the "right" set of breakpoints to install in the target VM. This analysis
now uses Java project dependencies by default.
To always install all enabled breakpoints, you can disable the new option Preferences > Java > Debug > Do not install breakpoints from unrelated projects
Note that not all projects use explicit Java project dependencies. E.g. OSGi bundles typically use a dynamically computed classpath where project dependencies are computed by PDE.
|Enabled assertions for new JUnit launch configurations||
Assertions are now enabled by default for new JUnit launch configurations. You can disable this on Preferences > Java > JUnit page: