The release notably includes the following Java 14 features:
JEP 361: Switch Expressions (Standard).
JEP 359: Records (Preview).
JEP 368: Text Blocks (Second Preview).
JEP 305: Pattern Matching for Instanceof (Preview).

Please note that preview option should be on for preview language features. For an informal introduction of the support, please refer to Java 14 Examples wiki.

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

For example, completing on :

Queue<String> queue = new L

prioritizes constructors for LinkedBlockingQueue, LinkedBlockingDeQueue and LinkedList.

Non-blocking completion is useful when completion proposals are long to compute, as it allows you to type or use other parts of the IDE in the meantime.

Some completion participants may prevent this option from being effective (typically if the Java completion extension doesn't declare requiresUIThread="false"), so the UI thread may still be used even if this option is set.
The open Java file editors need to be closed and reopened for this option to be effective.

The options for a primitive statement are: Optional.empty() and Optional.of(). Type statements also have Optional.ofNullable().

Example for type objects:

The clean up removes parenthesis for a single untyped parameter, return statement for a single expression and brackets for a single statement. It replaces a lambda expression by a creation or a method reference when possible.

To select the clean up, invoke Source > Clean Up..., use a custom profile, and on the Configure... dialog select Simplify lambda expression and method reference syntax on the Code Style tab.

Beware! If you create Map implementations that don't follow the Map specification, this cleanup may break the behavior (a size() method that changes the values, an iterator that destroys the items...).

For example, selecting the lines as shown:

and right-clicking and selecting Surround With -> Try-with-resources Block

results in:

Previously, Eclipse would only warn you when you obtain a dubious value from a legacy API, but it would keep silent in the opposite case: passing a value of an annotated type into legacy API. Still in specific situations this can cause a NullPointerException to be thrown in your null-checked code:

The console shows an exception thrown from within your checked main method (see the class-level @NonNullByDefault). It also shows the new warning, which Eclipse raises to alert you of this danger.

Hint: The shown code assumes the list names to have type List<@NonNull String>, but the legacy method Legacy.printNames() succeeds to taint this list by inserting a null element. This goes unnoticed because that method views the list has having type List<String>, with no nullness constraint on the type argument.

By default this problem is raised at level info, but the severity can be configured in the compiler settings:

Most importantly, the analysis now consistently considers resources (=values of type AutoCloseable) which are acquired using a method call, where previously under some circumstances resource allocation got unnoticed if it was wrapped in a factory method, like in the following example:

makePrintWriter("/tmp/log.txt").printf("%d", 42);
// a PrintWriter is never closed!

Second, resource leak analysis now leverages knowledge about well-known resource classes that support fluent programming, i.e., instance methods which return this to enable chains of method calls. Where a naive analysis could consider the method result as a new resource coming into scope, special knowledge about these classes informs the analysis that it is one and the same resource. This concerns the following system classes:

from java.io

CharArrayWriter, Console, PrintStream, PrintWriter, StringWriter, Writer

from java.nio.channels

AsynchronousFileChannel, AsynchronousServerSocketChannel, FileChannel, NetworkChannel, SeekableByteChannel, SelectableChannel, Selector, ServerSocketChannel

from java.util

Formatter

The following example is now understood to be safe, because analysis understands that the resource returned by append() is the same as the initial pw:

PrintWriter pw = new PrintWriter("/tmp/log.txt");
pw.printf("%d", 42).append(" is the answer").close();

Generally, resource leak analysis was made more precise regarding several specific situations.

A new bundle services the org.eclipse.jdt.core.JavaCodeFormatter application. This new bundle is part of the JDT feature. Users who are not using the JDT feature to define their set of bundles will need to add org.eclipse.jdt.core.formatterapp to their set of bundles.

Some limitations apply: The feature should be considered a MVP (Minimally Viable Product). It is not yet possible to reference non-public fields and methods of the enclosing class. The evaluation may not work in system classes and some generic contexts.