Java development tools
- Java Editor
- Java Views and Toolbars
- Java Formatter
- Java Compiler
- Working with Annotations
|Convert method reference to lambda and back
New Quick Assists (Ctrl+1) have been added to convert...
|Add inferred lambda parameter types
You can explicitly add the inferred types of the parameters in a lambda expression by invoking the Quick Assist (Ctrl+1) - Add inferred lambda parameter types:
|Add and remove parentheses around lambda parameter
New Quick Assists (Ctrl+1) have been added to add and remove the parentheses around lambda parameter:
|New Java editor templates
New templates (try_finally, finally, lock) have been added to insert commonly occurring patters in concurrent programming:
Java Views and Toolbars
|New icon set in JDT
The JDT project now uses png icons to render better with a dark theme. The following screenshot shows a few
example icons, on the left side is the old gif icon, on the right side the new png icon.
|Extension point for third-party formatters
JDT now provides an extension point (
org.eclipse.jdt.core.javaFormatter) to allow third-party source code formatters as extensions.
The default code formatter is used if no third-party formatter is provided.
|ECJ requires 1.7 Java runtime
|JDT Core projects are now compiled at 1.7 compliance level. As a result, a Java Runtime of 1.7 or above is required to run the Eclipse compiler.
|Improved compiler performance
|Significant performance improvements have been made to the Java compiler on generics-heavy code. Details on affected scenarios, fix and performance results can be found on bug 434326
|Unused exception parameters
A new compiler option to report unused exception parameters in try-catch statements has been added. The option
is set to
Ignore by default.
|Improved flow analysis for loops
Flow analysis has been improved to more precisely capture the flow of null values in loops.
This mainly achieves a reduction of false positive reports from null analysis.
Previously, example method "test1" would raise a potential null pointer warning at point (3). To correct this issue the merging of information leading towards point (3) has been improved to correctly see that the null value from point (1) can never reach point (3).
In example method "test2" JDT previously reported a redundant null check at (3), because analysis didn't see that the assignment directly above could indeed assign a non-null value.
In example method "test3" it was reported that "o can only be null" at (3), because the information from the two null-assignments wrongly overruled the one assignment from non-null. With improved analysis this is now softened to saying "o may be null".
The graph on the right hand side illustrates the new composition of flow information: for each relevant point (3) inside a loop, the analysis first merges the flows that lead into (1). This result is concatenated with the partial flow (b.c), which leads from the loop start to point (3). Improved precision has thus been achieved within the design limits of a single AST traversal in order to minimize impact on compiler performance.
|More precise flow analysis
Flow analysis, as performed by the compiler to warn the user about potential programming problems,
has been made smarter. Some examples are:
Working with Annotations
Annotation-based null analysis can now leverage externally defined annotations that are attached to a library.
Previously, annotation-based null analysis was significantly limited by the fact that many 3rd party libraries have no null annotations in their API. This implied that any errors caused at this interface could not be detected by the analysis, and even worse, implementors of library-defined interfaces could not use any intended contracts, because any null annotations in overriding methods were flagged as incompatible with the super version.
JDT now supports the concept of "external annotations". A user can specify null annotations in separate files and attach these to a given library. The compiler will take external null annotations into consideration for its null analysis.
External annotations can be provided as a directory tree of individual text files or as a zip file. External annotations can be attached to a JRE (per workspace) and to arbitrary libraries (per project).
A new command Annotate is provided when browsing attached source code of a library using the class file editor.
Two pre-requisites must be met for using this command:
Users may select any type in the signature of a library method or field, and invoke Annotate -
either using the context menu, or by pressing Ctrl+1.
Proposals will be offered for marking the selected type as
After selecting a proposal, the compiler will immediately leverage the new annotation for its null analysis.
|Render all annotations in Javadoc hovers
Javadoc hovers can now render all annotations, including type annotations (having a
In particular, working with external annotations benefits from this feature, as the Javadoc hover now shows these external annotations as well, thus providing the attached information right where it is needed. Also the Javadoc view is able to show the same information.
Javadoc hover after having applied the Annotate command for the return type of
As of Eclipse 4.5, this feature is only enabled in projects that are configured for annotation-based null analysis.
|Shortcut for Skip All Breakpoints
Ctrl+Alt+B has been added as the shortcut for Skip All Breakpoints.
|Add Watchpoint for final variables
You can now add a Watchpoint for non-constant final variables:
This cannot be implemented for final variables with compile-time constant values because Java compiles the constant value into class files and leaves no trace of a field access at points where the final field is read.
|The org.junit bundle has been updated to JUnit 4.12.
|Show skipped tests only in JUnit view
The JUnit view now has a filter to show only the skipped (ignored or assumption failed) tests:
|Re-run parameterized JUnit tests
The JUnit view now allows you to re-run groups of parameterized tests, or actually any
kind of tests that are run by a specialized runner and add another level of grouping
in the JUnit view.
See the full story in Moritz' Blog.