Here are descriptions of some of the more interesting or significant changes made to the Java development tools for the Juno (3.8 and 4.2) release of Eclipse. They are grouped into:
See also the What's new for Java 7 for features initially added in the 3.7.1 maintenance release.
See also the Eclipse Platform What's New document for changes in the Platform.
Java Editor |
|
Quick Assist to convert enhanced for loop |
Ever encountered an enhanced for loop and needed access to the Iterator or to the loop index?
Now, you can just use a Quick Assist (Ctrl+1) to convert the loop:
|
'*.class without source' file type |
The new *.class without source file type allows to associate an internal or external editor
to class files that have no source attached. This e.g. allows to open the class file in a decompiler:
|
Quick assists to reorganize property keys |
If you use Eclipse-style externalized strings, the following new quick assists make it easier to
reorganize keys inside the Properties File Editor:
|
Javadoc hover shows parameter annotations |
Javadoc hovers now render the annotations on method parameters:
|
CamelCase in Quick Outline |
The Quick Outline (Ctrl+O) and Quick Hierarchy (Ctrl+T) in the Java Editor now also
support camelCase matching on the element name, quite similar to the Open Type dialog and Content Assist.
|
Improved bracket matching support in Java editor |
The Java editor now supports highlighting of enclosing brackets.
Also, the Navigate > Go To > Matching Bracket action (Ctrl+Shift+P) now works everywhere in a file. If a bracket is not selected before invoking the action, the action navigates to the nearest enclosing end bracket. On invoking the action a second time, it navigates to the corresponding start bracket. On the third invocation, the original selection is restored. So far, a matching bracket was found when the caret was placed immediately after a bracket. Now, a matching bracket is found both when the caret is placed either immediately before or immediately after a bracket. You can hover over a closing curly brace and see the source near the matching opening brace in a hover. This is helpful when you want to see the code near the start of a long code block. The hover also tells the number of lines in the code block. The hover is also useful to temporarily 'highlight' a short code block. |
Default implementations for correction proposals |
JDT now provides the following default implementations for correction proposals that can be used to contribute quick fixes and quick assists.
|
Content assist in package-info.java |
Content assist (Ctrl+Space) is now available inside package-info.java, which is used to declare package-level annotations and Javadocs.
|
Java Formatter |
|
Java Compiler |
|
New options to detect resource leaks | The compiler can now detect leakage of resources i.e. local variables of type
java.lang.AutoCloseable (compliance >= 1.7) and java.io.Closeable (compliance <= 1.6).
When the Resource leak option on the Java > Compiler > Errors/Warnings preference page is enabled,
the compiler will issue an error or a warning if the
When you enable the Potential resource leak option on the Java > Compiler > Errors/Warnings preference page,
the compiler will issue an error or a warning if the
|
New options to suggest use of try -with-resources statement |
The compiler can now suggest using try with resources statement
for resources of type java.lang.AutoCloseable when
such resources have been explicitly closed but not declared in try -with-resources statements.
This only works in compliance 1.7 or above.
|
New Batch compiler warning options | Two new batch compiler options are now available to configure the
compile time warnings:
|
New build path option to warn when a source folder's output location overlaps another source folder | JDT now shows a build path error when a source folder's output location overlaps another source folder.
This error can be configured on the Java > Compiler > Building > Output location overlaps source location preference page.
|
Annotation-based null analysis |
JDT can now be configured to use annotations designated as null annotations to
perform enhanced inter-procedural null analysis. This feature can be enabled in
Preferences > Java > Compiler > Errors/Warnings > Null analysis:
You can use either the default annotations bundled with JDT or use your own annotations
as null annotations. In addition to enabling the null analysis, the annotations need to be on the
Java build path of your project. The default annotations can be found in the org.eclipse.jdt.annotation JAR
in the When annotation-based null analysis is enabled, JDT issues new diagnostics based on the nullness of a variable or a method return type as specified by a null annotation. Similar diagnostics are also elicited when the value assigned/returned may potentially be null or has unknown nullness. Overriding methods are also checked for correctness: You can also use the As a result of annotating method signatures, the existing intra-procedural null analysis has even more information because of user-specified annotations and thus provides better results. In the example below, the compiler would not have been able to evaluate the null status of parameter 'obj' without the null annotation. Note: This is the first version of this feature. We are working on making this easier to consume in Java project setups, and we will also add quick fixes. The implemented features are complete and tested, but e.g. support for annotating fields or APIs from third-party libraries is currently missing. |
Null analysis for fields |
JDT can now raise null related errors/warnings for fields. You can configure null analysis for
fields in
Preferences > Java > Compiler > Errors/Warnings > Null analysis.
This option can be enabled for the command line batch compiler using the |
Batch compiler options for using null annotations |
You can now configure the batch compiler to use annotations for null analysis by passing the token nullAnnot(nullable|nonnull|nonnullbydefault) to the -warn option,
where nullable, nonnull and nonnullbydefault are the fully qualified names of the annotation types to be used for null analysis. You can use nullAnnot alone
to use JDT's default annotations.
In addition, you can use the -nonNullByDefault token to globally use nonnull as the default when annotation-based null analysis is enabled. This implies that all types in method signatures without a null annotation are considered as specified non-null. |
Smarter resource leak detection |
JDT now performs smarter analysis so that resource leak related errors/warnings
(configured by the options Resource leak and Potential resource leak
in Preferences > Java > Compiler > Errors/Warnings > Potential programming problems) are no longer
reported on practically unimportant cases. Some examples where the absence of a close() call does not
trigger any error/warning are given below:
|
Selectively ignore errors/warnings from source folders |
You can now configure JDT to ignore optional errors/warnings from certain source folders.
Project properties > Java Build Path > Compiler > Source.
With this option set to Yes, JDT will suppress errors/warnings configured in the Preferences > Java > Compiler > Errors/Warnings page. This can be desirable for source folders that contain auto-generated classes or tests. |
Improved messages for null analysis problems |
The wording of several error messages and compiler options in
Preferences > Java > Compiler > Errors/Warnings > Null analysis has been improved:
|
Detection of missing default nullness annotation |
You can now configure JDT to detect a missing default nullness annotation when using the annotation-based null analysis.
When Preferences > Java > Compiler > Errors/Warnings > Null analysis > Missing '@NonNullByDefault' annotation on package
is enabled, JDT will issue an error/warning in the following cases:
Note that the option Use non-null as workspace wide (or project-wide) default has been withdrawn. Instead, you can enable the Missing '@NonNullByDefault' annotation on package option and make sure you specify the default nullness annotation on all types/packages. |
Null analysis treats org.eclipse.core.runtime.Assert like Java assert |
Since org.eclipse.core.runtime.Assert is often used just like the Java assert keyword, JDT's null analysis considers
the boolean expression passed into the former as always true after the Assert reference, since if the condition did turn out to be false,
the control flow will never go further than the org.eclipse.core.runtime.Assert reference.
|
Null analysis for fields withdrawn | "No man loves the bearer of bad tidings", said Sophocles. While we're proud to announce all the recent enhancements in JDT's null analysis, we have decided to withdraw the support added for null analysis of fields in Juno M5 so that a more general and configurable solution could be considered in future without being constrained by the present implementation. Stay tuned! |
Resource leak detection improved and enabled by default |
Resource leak detection as introduced in JDT Juno M3 is now less aggressive if a resource
is shared between methods, possibly via a field, where any party accessing the resource
could possibly issue the desired call to close(). This, along with some fine tuning of the
analysis, results in a greatly reduced number of false positives. Thus, the detection of a
definite resource leak is now much more reliable and reporting is set to warning by default.
This can be configured in the Java > Compiler > Errors/Warnings preference page.
|
Incomplete switch over enum |
JDT now raises a new warning whenever a switch on an enum value lacks a default case, and the option
Preferences > Java > Compiler > Errors/Warnings > Incomplete 'switch' cases over enum is enabled.
Note that in cases like the above, the warning also helps to understand another
error against the last statement: |
Enhanced diagnostics for detection of incomplete switch statements |
JDT now provides additional configurable diagnostics to flag an incomplete switch statement.
When you enable the option Preferences > Java > Compiler > Errors/Warnings > Switch is missing default case, JDT will flag switch statements with a missing default case, because such a switch statement can e.g. result in variables left uninitialized. When you enable the sub-option Preferences > Java > Compiler > Errors/Warnings > Signal even if default case exists for the Incomplete switch cases on enum option, JDT will flag switch statements over an enum type which may have an enum value covered only through a default statement, but not directly through a case statement. When new enum constants are added, this option will help in detecting the switch statements that do not cover the new value. |
Java Views and Dialogs |
|
Encoding for source attachments |
You can now specify the encoding for source attachments for libraries e.g.
in Build Path > Libraries > expand the library > Source attachment > Edit...
|
Faster search with pre-built indexes |
Note: This feature is mainly intended for plug-ins that implement their own classpath container, not for the end user.
You can now tell JDT search to use pre-built indexes instead of having the compiler generate the indexes the first time a JAR is added to the classpath. This prevents indexing from occurring on the user's machine and lets the user obtain first search results faster. You can specify the index file as a classpath attribute See Help > JDT Plug-in Developer Guide > Programmer's Guide > JDT Core > Indexes for the Java search for more details. |
Export detail formatters |
Detail formatters can now be exported as separate preferences. Previously the only way to share detail formatters was to export
all of your workspace settings.
|
Highlighting on Errors/Warnings preference pages |
On Errors/Warnings preference pages, it is sometimes hard to see which item is selected, especially
when you opened the dialog via the "Configure Problem Severity" button.
|
Show Monitors on by default |
The default setting for displaying monitor information in the Debug view is now set to on.
This change only affects new workspaces and does not change existing settings.
Showing monitor information can be turned on or off using the Java > Show Monitors view action within the Debug view. |
Toggle breakpoint modifier keys |
There is now support for modifier keys while toggling breakpoints in the Java editor:
|
JUnit |
|
JUnit 4.10 | The JUnit 4 version shipped with Eclipse has been updated to 4.10. |