What's New in Luna (JDT)

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

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

Java Editor

Quick fix to change project compliance and JRE to 1.8 A quick fix Change project compliance and JRE to 1.8 is provided to quickly change the current project to be compatible with Java 8.

Migrate anonymous class creations to lambda expressions and back You can convert anonymous class creations to lambda expressions (and back) by invoking the Quick Assists (Ctrl+1):
  • Convert to lambda expression
  • Convert to anonymous class creation


anonymous class with a 1-line method body

After the Quick Assist (Ctrl+1), the 6 lines are condensed into 1:

lambda expression -- everything on 1 line

Or invoke Source > Clean Up..., use a custom profile, and on the Configure... dialog select Convert functional interface instances and Use lambda where possible on the Code Style tab.
Change lambda expression body block to expression and back You can convert the body of a lambda expression from block to expression (and back) by invoking the Quick Assists (Ctrl+1):
  • Change body expression to block

    Change body expression to block

  • Change body block to expression

    Change body block to expression

View the method implemented by the functional interface instances To view the method implemented by the functional interface instances, you can hover on:
  • '->' in a lambda expression

Hover on '->' in lambda to show functional method

  • '::' in a method reference

Hover on '::' in method reference to view functional method

Quick Fixes to create 'for' loops A set of new quick fixes can create for loops that iterate over a given expression.

For arrays:

  • Create an enhanced for loop
  • Create a for loop using an index

For Collections:
  • Create an enhanced for loop
  • Create a for loop using an Iterator
For Lists:
  • Create a for loop using an index and get(i)

Enabled coloring of variables Parameter variables and local variables are now colored by default:

This can be disabled or configured with different colors and styles on the Java > Editor > Syntax Coloring preference page.

Java Formatter

Option to control lambda code formatting New options are provided in the formatter page to configure the formatting of lambda expressions.
  • Configure the position of braces within lambda body:

  • Configure whitespace before and after the arrow operator of lambda:

Formatter profiles can be configured on the Java > Code Style > Formatter preference page.

Java Compiler

Java 8 Java™ 8 is here, and JDT fully supports it. The Eclipse compiler for Java (ECJ) implements all the new Java 8 language enhancements.
Option to control generation of method parameter attributes in class files In 1.8 compliance mode, you can enable the generation of method parameter attributes in class files:

Option to store method parameters in class files

Contributed VMs are more recognizable You can't remove VMs that have been contributed to Eclipse via the org.eclipse.jdt.launching.vmInstalls extension point.This fact is now more recognizable:

The Installed JREs preference page showing a contributed VM install

Null type annotations With the advent of "type annotations" as introduced in Java 8 via JSR 308, JDT takes null pointer analysis to the next level.

This feature requires a set of nullness annotations declared with @Target({TYPE_USE}), which JDT ships as version 2.0.0 of the org.eclipse.jdt.annotation bundle.

With these annotations, nullness can be considered as an intrinsic part of the type system, allowing the compiler to perform null type checking along with each task of type checking. This is a major step towards systematically detecting all possible NullPointerExceptions in a program.

The most obvious benefit is in annotating type arguments of generic types:

null annotated generics (1)

The example shows diverse usage of null-annotated type arguments. While most of the code has been checked to be safe, the compiler directly points out one obvious bug: in is declared with a nullable type, and hence cannot be passed into add() of a list of nonnull elements.

null annotated generics (2)

In this variant an error is detected by recognizing that string has been extracted from a list that may contain nulls, hence passing this value into a Predicate expecting a nonnull argument is wrong.

For a comprehensive description of type annotation based null analysis see the online help.

While potentially, the new approach could lead to an explosion of the number of annotations, also @NonNullByDefault has become much more powerful, such that programs not using any null values can be fully checked with just a single annotation:

null annotated generics (2)

The @NonNullByDefault annotation in line 7 affects most types in the example (with the exception of local variables, which are inferred using flow analysis). The compiler directly points out the single bug in the safe_ methods: the type argument of list result defaults to '@NonNull String', hence passing null to its add() method is now wrong.

In line 27 all null-defaults are canceled for the scope of method unprotectedClient(). Here we simulate the interface between un-annotated (legacy) code and code governed by @NonNullByDefault. We can observe that all arguments and local variables from the legacy code require unchecked conversions when being passed into the annotated code. In particular note that myStrings lacks two annotations required by the method safeFilter(): the List should be nonnull, and so should be its type argument.

Migrating projects using null annotations for use in Luna The switch from declaration annotations (Java 5) to null type annotations (Java 8) brings a few unavoidable incompatibilities. Developers already using null annotations are advised to carefully read the compatibility notes.

Main points to observe:

Project configuration
No matter if you are adopting null type annotations or continue to use old-style null annotations: always refer to the org.eclipse.jdt.annotation bundle using a suitable version range, either [1.1.0,2.0.0) for declaration annotations or [2.0.0,3.0.0) for type annotations. This is important, because Eclipse now ships with both versions of the annotation bundle.
As an alternative, OSGi/plug-in projects may use a target definition for explicitly selecting the appropriate version of the annotation bundle.
Syntax changes
When migrating to null type annotations, your code may need to be changed if you have null annotations attached to an array type or to a qualified type reference. The latter may simply create a new compile error, while the former implicitly changes its meaning.
ECJ requires 1.6 JRE The JDT Core project has moved to Java 1.6 compliance level. This means the command line compiler now requires JRE 1.6 or above to run.
A man page is available for ECJ batch compiler A UNIX like man page is available for the batch compiler. This man page essentially lists down the options and the corresponding usage information as found in this section.

Information in the man file can be read by the command "man <path_to_ecj.1>" in command prompt mode.

Java Views and Dialogs

Option to fine-grain Java search to limit to method reference expressions The Java search for method and constructor can now be limited to method reference expressions.

This option can be configured by clicking the hyperlink next to Search > Java Search > Limit To > Match locations:


Java 8 debug support Java Debugger has been enhanced to support Java 8 key features like:
  • Evaluating expressions and variables from the context of interface methods
  • Java Application can now be executed from the static main method in interface (without public modifier also)
  • Breakpoints can be added inside lambda expressions
See here for details on debugger enhancements.
Improved HCR for member types Hot Code Replace (HCR) has been improved in the Java debugger to ensure the correct method is dropped to in member types (inner / anonymous / local classes).

For more information see the bugzilla entry.


Failure trace font for the JUnit view The font for the failure trace in the JUnit view is now configurable on the General > Appearance > Colors and Fonts preference page.