What's New in Neon (JDT)

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

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

We also recommend to read the Tips and Tricks.

Java Editor

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 selection proposes all results containing selection as a substring.

Popup with proposals like addSelectionListener(..), getSelection(), etc.

This feature can be disabled using the Show substring matches option on the Java > Editor > Content Assist preference page.

ifNotNull/ifNull templates The Java editor now offers default templates for creating "== null" and "!= null" checks.

Rename options 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):

Assign all parameters to new fields

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 @Retention, @Target and @Documented meta-annotations along with their applicable values while creating a new Java annotation type.

Grouping of referenced libraries in Project Explorer The Project Explorer view now groups referenced libraries in a new container node.

View menu > Show 'Referenced Libraries' 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.

Java Compiler

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).

Null Analysis

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 @NonNull or a @Nullable type as substitution for the "free type variable" <T>, the implementation of that class must account for the worst in both directions:

  • To anticipate a @NonNull type, each field typed to a free type variable must be initialized with a non-null value, and passing null where T is expected is illegal
  • To anticipate a @Nullable type, each dereference must be preceded by a null check.

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.

configuration options for new diagnostics

(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.
If the library type is instantiated with a @NonNull type as the type argument, we generally want to interpret the mentioned return type as non-null, too. This is problematic only for some "legacy" methods, which may return null without declaring so. The most prominent example is java.util.Map.get(K) (see also the news entry on external annotations, which also demonstrates the clean solution to this issue).

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 list and map provide @NonNull String as a type argument, hence the return types of both get methods are interpreted as non-null. For List this is desired, for Map it is a bug.

The dilemma can be resolved by adding a (possibly empty) external annotation file (.eea) to each affected library class. By using an empty annotation file, the user signals that all types in this class should be interpreted verbatim (like in the List case - use with care). In the other case, the missing @Nullable annotation should be added as an external annotation (like in the Map case).

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, org.eclipse.jdt.annotation.Checks, has been included in the bundle org.eclipse.jdt.annotation_2.1.0 containing helper methods for typical idioms for improving and documenting null safety.

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 @NonNull annotation to the local variable.

While this may not produce correct code, it tells the compiler your intention to not allow null in this variable, and subsequently the compiler will answer with more helpful warnings or errors pointing to the root problem. In the given example, it will alert you of subtleties about using unconstrained type variables (see also Improved null analysis with generics):

Java Formatter

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: