Google Git
Sign in
eclipse / www.eclipse.org / eclipse / news / 3e86d52d30dd3eab0b4783d2dda1322d2e5d7af5 / . / 4.8 / jdt.html
blob: d929145c2dd89e99bbfad095dcf217a035e6bd59 [file] [log] [blame]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="copyright" content="Copyright (c) Eclipse contributors and others 2018. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page."/>
<meta http-equiv="Content-Language" content="en-us"/>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<link rel="STYLESHEET" href="news.css" type="text/css"/>
<style type="text/css">
body {max-width: 900px;}
table.news col.title {width: 30%;}
/*img {max-width: 520px;}*/
table.news {table-layout: fixed; border-collapse: collapse; width: 100%;}
table.news td {border-top: solid thin black; padding: 10px; overflow: visible;}
table.news tr {vertical-align: top;}
table.news tr td.section {font-size: 20px; font-weight: bold;}
table.news tr td.title {vertical-align: top; font-weight: bold;}
table.news tr td.content {vertical-align: top;}
ul {padding-left: 13px;}
</style>
<title>Eclipse Project Photon - New and Noteworthy</title>
</head>
<body>
<h2>Java development tools</h2>
<ul>
<li><a href="#Java10">Java&trade; 10 Support</a></li>
<li><a href="#Java9">Java&trade; 9 Support</a></li>
<li><a href="#JUnit">JUnit</a></li>
<li><a href="#JavaEditor">Java Editor</a></li>
<li><a href="#JavaViewsAndDialogs">Java Views and Dialogs</a></li>
<li><a href="#JavaCompiler">Java Compiler</a></li>
<li><a href="#JavaFormatter">Java Formatter</a></li>
<li><a href="#Debug">Debug</a></li>
<li><a href="#JDTDev">JDT Developers</a></li>
</ul>
<table class="news">
<colgroup>
<col class="title" />
<col />
</colgroup>
<tbody>
<!-- ******************* Java 10 Support ************************************* -->
<tr>
<td id="Java10" class="section" colspan="2">
<h2>Java&trade; 10 Support </h2>
</td>
</tr>
<tr id="java-10">
<td class="title">Eclipse support for Java&trade; 10 </td>
<td class="content">
<a href="http://docs.oracle.com/javase/10/">Java&trade; 10</a> is here, and JDT supports it completely.
<ul>
<li>The Eclipse compiler for Java (ECJ) implements the new Java 10 <a href="https://docs.oracle.com/javase/10/language">language enhancement</a>
which is the support for <a href="http://openjdk.java.net/jeps/286" target="_top"><b>local variable type inference (JEP 286)</b></a>.</li>
</ul>
<ul>
<li>
<p><b>Addition of Java 10 JRE</b></p>
<ul>
<li>A Java 10 JRE is recognized by Eclipse for launching. It can be added from the <b>Window > Preferences > Java > Installed JREs > Add...</b> page.
It can be added from the <b>Package Explorer</b> as well using the project's context menu.
<p><img src="images/j10.png" alt=""/></p>
</li>
<li>An option to set compiler compliance to 10 on a Java project is provided.
<p><img src="images/j10.compliance.png" alt=""/></p>
</li>
</ul>
</li>
<li>
<p><b>Support for <code>var</code> compilation</b></p>
<ul>
<li>Eclipse supports compilation of <code>var</code> as shown below:
<p><img src="images/var.compile.png" alt=""/></p>
</li>
<li>When the type of <code>var</code> cannot be inferred, it is flagged as a compiler error as expected.
An example is shown below:
<p><img src="images/var.nocompile.png" alt=""/></p>
</li>
</ul>
</li>
<li>
<p><b>Code Completion for <code>var</code></b></p>
<ul>
<li>Code completion is offered at places where <code>var</code> is allowed.
<p><img src="images/var.complete.png" alt=""/></p>
</li>
<li>Code completion of var is not offered at places where <code>var</code> is not allowed.
<p><img src="images/var.nocomplete.png" alt=""/></p>
</li>
</ul>
</li>
<li>
<p>Hover over <code>var</code> shows the javadoc of the inferred type.</p>
<p><img src="images/var.hover.png" alt=""/></p>
</li>
<li>
<p>Quick Assist to convert from <code>var</code> to the appropriate type is provided.</p>
<p><img src="images/var.vartotype.png" alt=""/></p>
</li>
<li>
<p>Quick Assist to convert from type to <code>var</code> is provided.</p>
<p><img src="images/var.typetovar.png" alt=""/></p>
</li>
</ul>
</td>
</tr>
<tr id="quickfix-change-compliance-10">
<td class="title">Quick fix to change project compliance and JRE to 10</td>
<td class="content">
A quick fix <b>Change project compliance and JRE to 10</b> is provided to quickly change the current project to be compatible with Java 10.
<p><img src="images/quickfix-change-compliance-10.png" alt=""/></p>
</td>
</tr>
<!-- ******************* Java 9 Support ************************************* -->
<tr>
<td id="Java9" class="section" colspan="2">
<h2>Java&trade; 9 Support </h2>
</td>
</tr>
<tr id="java-9">
<td class="title">Eclipse support for Java&trade; 9</td>
<td class="content">
<a href="http://docs.oracle.com/javase/9/">Java&trade; 9</a> is here, and JDT supports it completely:
<ul>
<li>The Eclipse compiler for Java (ECJ) implements all the new Java 9 <a href="https://docs.oracle.com/javase/9/language">language enhancements</a></li>
<li>Updated significant features to support Java Modules, such as compiler, search and many editor features.</li>
</ul>
<p><b>Note:</b>
It is not mandatory to run Eclipse with Java Runtime 9 to get the Java 9 support. However,
a Java runtime 9 is required to be on a project's build path
to compile a modular project against the system modules.
</p>
<ul>
<li>
<p>When a Java Runtime 9 is added to a project's build path, the system modules
are listed under the System library in the package explorer:</p>
<p><img src="images/java9-package-explorer.png" alt=""/></p>
</li>
</ul>
<ul>
<li>
<p>An existing non-modular Java project can be quickly converted to a module by
creating a module-info.java for that project. This feature can be availed once the project has
been moved to compliance 9:</p>
<p><img src="images/java9-create-module.png" alt=""/></p>
</li>
</ul>
<ul>
<li>
<p>With Java 9 support, a library or a container can now be added to the
module path as opposed to the classpath:</p>
<p><img src="images/java9-module-path.png" alt=""/></p>
</li>
</ul>
<ul>
<li>
<p>Once an entry has been added to a project's module path, its contents and encapsulation
properties can further be modified by double-clicking on the <b>Is modular</b> node
(or using the <b>Edit</b> button while <b>Is modular</b> is selected):</p>
<ul>
<li>
On the <b>Contents</b> tab individual modules inside a container like <b>JRE System Library</b>
can be included or excluded by moving the module from left-to-right or vice versa.
Modules shown in the lower right box are implicitly included, because they are required
by one or more modules in the upper right box.
<p><img src="images/java9-module-container-contents.png" alt="Configuring the Contents of a module container"/></p>
</li>
<li>
On the <b>Details</b> tab the encapsulation of given modules can be further influenced.
The following example shows how module <code>module.one</code>
can be made to export one of its packages to the module of the current Java project:
<p><img src="images/java9-module-properties.png" alt=""/></p>
</li>
<li>Toggling <b>Defines one or more modules</b> (see above screenshot) lets you specify
whether a given regular (non-modular) jar file or project should be considered as an "automatic module".
As a consequence of changes here, the entry will move to the Modulepath or Classpath accordingly.</li>
</ul>
</li>
</ul>
<ul>
<li>
<p>Java search now includes a new search scope - Module:</p>
<p><img src="images/java9-module-search.png" alt=""/></p>
</li>
</ul>
<ul>
<li>
<p>When a Java Runtime 9 is added to a project's build path, the launch configurations are created with "Dependencies" tab and not the old "Classpath" tab.</p>
<p>User can change the JRE of launch configuration and on the confirmation, the tab changes from "Classpath" to "Dependencies" or vice versa. </p>
<p><img src="images/changing-tabs-launch-config.png" alt=""/></p>
<p>If Java project is modular and module is described in module_info.java, most of the dependencies will be defined in the Modular Entries.</p>
<p><img src="images/modular-dependencies.png" alt=""/></p>
<p>If Java project is not modular, most of the dependencies will be defined in the Classpath Entries.</p>
<p><img src="images/non-modular-dependencies.png" alt=""/></p>
</li>
</ul>
<ul>
<li>
<p>A new quick fix is offered on import statements to fix issues that are reported due to <b>missing module dependency</b></p>
<p>This QuickFix is applicable if the project is a Java9 project and has a <code>module-info.java</code>.</p>
<p>The quick fix can be invoked from the editor:</p>
<p><img src="images/java9-module-requires-on-import.png" alt=""/></p>
<p>Before the quickFix is applied the module-info file looks as below</p>
<p><img src="images/java9-before-adding-module-requires-on-import.png" alt=""/></p>
<p>After the quickfix is invoked, <code> module-info.java</code> will be updated to include <code>requires 'MODULE_NAME'</code></p>
<p><img src="images/java9-after-adding-module-requires-on-import.png" alt=""/></p>
</li>
</ul>
<ul>
<li>
<p>A new quick fix is available when you have an unresolved type in a Java file. If the unresolved type can be found in a java9 module, a quick fix will be available to add an import type entry to your file reporting the error and add the required module dependency to <code>module-info.java</code> file.</p>
<p>This QuickFix is applicable if the project is a Java9 project and has a <code>module-info.java</code> file.</p>
<p>The quick fix can be invoked from the editor:</p>
<p><img src="images/java9-module-requires-and-import-on-missing-type.png" alt=""/></p>
<p>Before the quickFix is applied, the module-info file looks as below</p>
<p><img src="images/java9-before-adding-module-requires-on-import.png" alt=""/></p>
<p>After the quickfix is invoked, <code> module-info.java</code> will be updated to include <code>requires 'MODULE_NAME'</code></p>
<p><img src="images/java9-after-adding-module-requires-on-import.png" alt=""/></p>
<p>After the quickFix is applied, the required <code>import</code> statement is added to the file reporting error</p>
<p><img src="images/java9-after-adding-import-module-requires-and-import-on-missing-type.png" alt=""/></p>
</li>
</ul>
<ul>
<li>
<p>A new quick fix is available when you have an unresolved type on <code>service provider</code> in a provides directive in module-info.java file. If the unresolved type can not be found in the current module, a quick fix will be available to create a new class or an interface in the current module.</p>
<p>This QuickFix is applicable if the project is a Java9 project and has a <code>module-info.java</code> file.</p>
<p>The quick fix can be invoked from the editor:</p>
<p><img src="images/java9-module-provides-create-class.png" alt=""/></p>
<p><img src="images/java9-module-provides-create-interface.png" alt=""/></p>
<p>When the service is a class, the quick fix is proposed for creating a class.</p>
<p>When the service is an interface or an annotation, two quick fixes are proposed for creating a class or an interface.</p>
</li>
</ul>
</td>
</tr>
<tr>
<td class="title">New <code>--release</code> on the Java compiler preference page</td>
<td class="content">
<p>A new option <code>--release</code> is available on the Java compiler preference page.</p>
<p>This option will be enabled only if the JRE being used is a Java 9 or above.</p>
<p>Workspace Preference:</p>
<p><img src="images/java9_release_option_workspace_preference_page.png" alt=""/></p>
<p>Project Preference:</p>
<p><img src="images/java9_release_option_project_preference_page.png" alt=""/></p>
<p>In the past, it was possible to compile for an older version of the Java language.</p>
<p>However, the compiler always compiled against the platform APIs that is found in the project's build path.</p>
<p><b>For Example:</b> If the JRE being used is java 1.8 and the compliance level is set to 1.7, the API's that are available are from the Java8 library, even if they were not part of Java 1.7.</p>
<p>The new --release compiler option now allows the user to configure compilation against a platform API version of user's choice.</p>
<p><b>For Example:</b> Using --release option if the JRE being used is 9 and the compliance level is set to 1.7, the API's that are available will be from JRE 1.7 even if JRE 1.7 is not available in your workspace.</p>
<p>The --release option supports versions 1.6 and above. That is the --release option is enabled for JRE 9 and above, if the compliance is set to 1.6 or above</p>
<p>In the below picture, compliance is set to 1.5, therefore the --release option is disabled.</p>
<p><img src="images/java9_release_option_disabled_project_preference_page.png" alt=""/></p>
<p>The --release option is enabled by default for all new projects created using JRE 9 or above.</p>
</td>
</tr>
<tr>
<td class="title">Use <code>--release</code> option for Default Access rules and EE descriptor</td>
<td class="content">
<p>Java 9 onwards, Access rules intrinsic to JRE will not be available by default. Users must use the --release option to configure compilation against the version of Java library of his or her preference.</p>
<p>From Java 10 and beyond, API tools Execution Environment Descriptions will not be provided to determine if references are present in execution environment or not. Users must use the --release option to configure compilation
against platform API of his or her preference. If the user intends to enforce a particular version of Java for determining Java API references in a project, he or she can store this preference in the project settings.</p>
</td>
</tr>
<tr id="module-info-paste">
<td class="title">Paste module-info.java code in Package Explorer</td>
<td class="content">
You can now paste a snippet of code representing module-info.java directly into a source folder to create a module-info.java file.
For example, copy this code:
<pre>
import java.sql.Driver;
module hello {
exports org.example;
requires java.sql;
provides Driver with org.example.DriverImpl;
}
</pre>
Then, select a source folder in a Java 9 project in the <b>Package Explorer</b> view and use <b>Ctrl+V (Edit &gt; Paste)</b> to paste it.
This automatically creates a module-info.java file in the source folder with the copied content.
</td>
</tr>
<tr id="content-assist-module-declaration-name">
<td class="title">Content assist for module declaration name</td>
<td class="content">
Content assist <b>(Ctrl+Space)</b> support is now available for module declaration name.
<p><img src="images/content-assist-module-declaration-name.png" alt=""/></p>
</td>
</tr>
<tr id="quickfix-javadoc">
<td class="title">Quick Fix for <code>unresolved module</code> on module name in <code>requires directive</code></td>
<td class="content">
A new quick fix is offered on <b>requires</b> statements in the <b>module-info.java</b> file to fix issues that are reported due to unresolved module.
The below quick fix will be provided if the module related to the unresolved module error has its related classpath added to the classpath and not to the module path.
<p>This quick fix is applicable if the project is a Java 9 project and has a module-info.java file</p>
<p>This quick fix can be invoked from the editor.</p>
<p><img src="images/java9-module-requires-move-from-classpath-to-modulepath-quickfix.png" alt=""/></p>
<p>Before the quick fix is applied the classpath entries look as below: </p>
<p><img src="images/java9-module-requires-move-from-classpath-to-modulepath-CPE-before-quickfix.png" alt=""/></p>
<p>After the quick fix is applied the classpath entries look as below: </p>
<p><img src="images/java9-module-requires-move-from-classpath-to-modulepath-CPE-after-quickfix.png" alt=""/></p>
</td>
</tr>
<tr>
<td class="title">Quick fix for <code>Non-existing or empty package</code> on <code> exports directive</code></td>
<td class="content">
<p>A new quick fix is available when you have a <code> non-existing or an empty package</code> in an <code>exports directive</code> in module-info.java file.</p>
<p>This quick fix is applicable if the project is a Java9 project or above and has a <code>module-info.java</code> file.</p>
<p>The quick fix can be invoked from the editor:</p>
<p><img src="images/java9_quickfix_empty_nonexistant_package_on_exports_directive.png" alt=""/></p>
<p>A quick fix is provided to create either a Class, or an Interface or an Annotation or an Enum in the given package.</p>
<p>If the package does not exist, a new package is created and the new element is created in the package.</p>
</td>
</tr>
<tr id="newproject-modulefile">
<td class="title">Creation of <code>module-info.java file</code> on creation of a new Java9 Project</td>
<td class="content">
When creating a Java project with compliance Java 9 or above, a new option is offered for the creation of the <code>module-info.java</code> file.
<p>A new checkbox has been added in the Java Settings page (Page 2) of the <b>New Java Project</b> wizard. See images below. </p>
Page 1:
<p><img src="images/create_Java_Project_1.png" alt=""/></p>
Page 2:
<p><img src="images/create_Java_Project_2.png" alt=""/></p>
<p>The new checkbox for the creation of module-info.java file is checked by default.</p>
<p>When this checkbox is checked, upon project creation, the dialog for creation of a new <code> module-info.java </code> file will appear.</p>
<p><img src="images/create_module_info.png" alt=""/></p>
<p>Selecting <b>Don't Create</b> in the above dialog does not create the <code>module-info.java</code> file, but creates the project.</p>
</td>
</tr>
<tr id="override-dependencies">
<td class="title">Overriding modular build path dependencies for launching</td>
<td class="content">
Based on Java build path, a Java 9 module can have command line options. These options from build path can be overridden for launching programs in the module.
<b>Override Dependencies</b> button has been added to <b>Dependencies</b> tab:
<p>
<img src="images/override-dependencies-button.png" alt="Override Dependencies button" />
</p>
Dialog can be used to override modular dependencies:
<p>
<img src="images/override-dependencies-dialog.png" alt="Override Dependencies dialog" />
</p>
</td>
</tr>
<!-- ******************* JUnit ************************************* -->
<tr>
<td id="JUnit" class="section" colspan="2">
<h2>JUnit</h2>
</td>
</tr>
<tr id="junit-5-support">
<td class="title">Eclipse support for JUnit 5.1</td>
<td class="content">
<a href="http://junit.org/junit5/">JUnit 5.1</a> is here and Eclipse supports it.
<ul>
<li>
<p>Create a new JUnit Jupiter test via <b>New JUnit Test Case</b> wizard:</p>
<p><img src="images/new-junit-jupiter-test.png" alt=""/></p>
</li>
<li>
<p>Add JUnit 5 library to the build path:</p>
<ul>
<li>
<p>New JUnit Test Case wizard offers to add it while creating a new JUnit Jupiter test:</p>
<p><img src="images/add-junit-5-lib.png" alt=""/></p>
</li>
<li>
<p>Quick Fix <b>(Ctrl+1)</b> proposal on <b><code>@Test</code></b>, <b><code>@TestFactory</code></b>, <b><code>@ParameterizedTest</code></b> and <b><code>@RepeatedTest</code></b> annotations:</p>
<p><img src="images/add-junit-5-lib-quick-fix.png" alt=""/></p>
</li>
<li>
<p>Add JUnit library in Java Build Path dialog:</p>
<p><img src="images/add-junit-5-lib-java-build-path.png" alt=""/></p>
</li>
</ul>
</li>
<li>
<p>Create a JUnit Jupiter test method with the new <b>test_jupiter</b> template:</p>
<p><img src="images/junit-jupiter-test-method-template.png" alt=""/></p>
</li>
<li>
<p>Create a <b><code>@TestFactory</code></b> method with the new <b>test_factory</b> template:</p>
<p><img src="images/junit-jupiter-test-factory-template.png" alt=""/></p>
</li>
<li>
<p>JUnit Jupiter’s <code>Assertions</code>, <code>Assumptions</code>, <code>DynamicContainer</code> and <code>DynamicTest</code> classes are now added to <b>Eclipse Favorites</b> by default:</p>
<p><img src="images/content-assist-favorites.png" alt=""/></p>
<p>This allows you to quickly import the static methods from these classes in your code via Content Assist <b>(Ctrl + Space)</b> and Quick Fix <b>(Ctrl + 1)</b>.</p>
</li>
<li>
<p>View all the failures from grouped assertions in the same <b>Result Comparison</b> dialog opened from JUnit view:</p>
<p><img src="images/grouped-assertions-result-comparison.png" alt=""/></p>
</li>
<li>
<p>View the number of disabled tests and tests with assumption failures on hover in JUnit view:</p>
<p><img src="images/skipped-tests.png" alt=""/></p>
</li>
<li>
<p>Use <b>Go to File</b> action or just double-click to navigate to the test from JUnit view even when the test is displayed with a custom name:</p>
<p><img src="images/display-name.png" alt=""/></p>
</li>
<li>
<p>(Re-)Run a single <b><code>@Nested</code></b> test class by using the <b>Run</b> action in JUnit view or Outline view.
You can even right-click on a nested test class name in the editor and use the <b>Run As</b> action:
</p>
<p><img src="images/run-nested-class.png" alt=""/></p>
</li>
<li>
<p>The <b>Test Method Selection</b> dialog in JUnit launch configuration now shows the method parameter types also:</p>
<p><img src="images/test-method-selection-dialog.png" alt=""/></p>
</li>
<li>
<p>You can provide tags to be included in or excluded from a test run in the <b>Configure Tags</b> dialog of JUnit launch configuration:</p>
<p><img src="images/junit-tags.png" alt=""/></p>
</li>
<li>
<p>In JUnit Jupiter, a method parameter of type <code>TestReporter</code> can be used to publish additional data about the current test run which can be viewed in the <b>Console view</b>:</p>
<p><img src="images/junit5-test-reporter.png" alt=""/></p>
<p><img src="images/junit5-test-reporter-console-view.png" alt=""/></p>
</li>
</ul>
<p><b>Note:</b></p>
<ul>
<li>
If you are using an Eclipse workspace where you were running your JUnit 5 tests via <code>@RunWith(JUnitPlatform.class)</code> in Eclipse without JUnit 5 support
then you will have JUnit 4 as the test runner in their launch configurations. Before executing these tests in Eclipse with JUnit 5 support, you should either
change their test runner to JUnit 5 or delete them so that new launch configurations are created with JUnit 5 test runner while running the tests:
<p><img src="images/test-runner-update.png" alt=""/></p>
</li>
<li>
We do not support running tests in a setup where an old Eclipse build (not having JUnit 5 support) is using a new Eclipse build (having JUnit 5 support) as target. Also, developers who have
the JDT JUnit runtime bundles <code>(org.eclipse.jdt.junit.runtime, org.eclipse.jdt.junit4.runtime)</code> checked out and pull the latest changes will run into the above issue.
You are expected to use a new Eclipse build for the development.
</li>
</ul>
</td>
</tr>
<!-- ******************* Java Editor ************************************* -->
<tr>
<td id="JavaEditor" class="section" colspan="2">
<h2>Java Editor </h2>
</td>
</tr>
<tr id="quickfix-nnbd-on-package">
<td class="title">Quick Fix to add <code>@NonNullByDefault</code> to packages</td>
<td class="content">
A new quick fix is offered to fix issues that are reported when the <b>Missing '@NonNullByDefault' annotation on package</b> warning is enabled.
<p>If the package already has a <code>package-info.java</code>, the quick fix can be invoked from the editor:</p>
<p><img src="images/add-nnbd-existing-packageinfo.png" alt=""/></p>
<p>Otherwise, the quick fix must be invoked from the problems view, and will create a <code>package-info.java</code> with the required annotation:</p>
<p><img src="images/add-nnbd-create-packageinfo.png" alt=""/></p>
<p>When invoked from the problems view, both variations of the quick fix can fix the problem for multiple packages simultaneously.</p>
</td>
</tr>
<tr id="navigate-to-switch">
<td class="title">Navigate to 'switch' statement</td>
<td class="content">
You can now <b>Ctrl+click</b> or use <b>Open Declaration (F3)</b> on <code>case</code> or <code>default</code>
keywords to quickly navigate to the beginning of the <code>switch</code> statement.
<p><img src="images/navigate-to-switch.png" alt=""/></p>
</td>
</tr>
<tr id="escape-non-ascii-when-pasting">
<td class="title">Escape non-ASCII characters when pasting into a string literal</td>
<td class="content">
The <b>Java > Editor > Typing > Escape text when pasting into a string literal</b> preference option now has a suboption <b>Use Unicode escape syntax for non-ASCII characters</b>:
<p><img src="images/escape-non-ascii-settings.png" alt=""/></p>
When enabled, characters outside the visible ASCII range will be replaced by unicode escape sequences when pasted into a string:
<p><img src="images/escape-non-ascii-example.png" alt=""/></p>
</td>
</tr>
<tr id="jdt-syntaxcoloring-dark">
<td class="title">Improved Java syntax coloring in the dark theme</td>
<td class="content">
To improve readability in the dark theme, bold style usage has been reduced and some colors that were too close to each other have been altered.
<p><img src="images/java-syntax-dark.png" alt=""/></p>
</td>
</tr>
<tr id="link-in-element-info-jdt">
<td class="title">Improved coloring of links in code element information in the dark theme</td>
<td class="content">
The colors of links in code element information control now takes the color settings of the <b>Hyperlink text color</b> and the <b>Active hyperlink text color</b> from the <b>Colors &amp; Fonts</b> preference page into account.
The readability in the dark theme has been improved a lot by this.
<p>Before:<br/><img src="images/element_info_before.png" alt="before"/></p>
<p>After:<br/><img src="images/element_info_after.png" alt="after"/></p>
</td>
</tr>
<tr id="inherited-members-quick-outline-jdt">
<td class="title">Improved coloring of inherited members in the Quick Outline in the dark theme</td>
<td class="content">
The Eclipse default dark theme now includes styling of inherited members in JDT's <b>Quick Outline</b>. This improves readability in the dark theme a lot. The color can be configured via the <b>Java > Inherited Members</b> color definition on the <b>Colors and Fonts</b> preference page.
<p>Before:<br/><img src="images/inherited_before.png" alt="before"/></p>
<p>After:<br/><img src="images/inherited_after.png" alt="after"/></p>
</td>
</tr>
<!-- ******************* Java Views and Dialogs ************************************* -->
<tr>
<td id="JavaViewsAndDialogs" class="section" colspan="2">
<h2>Java Views and Dialogs</h2>
</td>
</tr>
<tr id="jdt-test-sources">
<td class="title">Test sources</td>
<td class="content">
In the <b>Java Build Path</b> project settings, there is now an attribute <b>Contains test sources</b> to configure
that a source folder contains test sources. (Note: test sources must have their own output folder). Similarly, for
projects and libraries there is an attribute <b>Visible only for test sources</b>. This setting also exists for
classpath containers, and if it is set to <b>Yes</b> for one of these, this value will be used for all contained
libraries and projects.
<p><img src="images/1-sourcefolder-settings-521330.png" alt=""/></p>
<p>Test source folders and dependencies are shown with a darker icon in the build path settings,
the package explorer and other locations. This can be disabled in <b>Preferences > Java > Appearance</b>: </p>
<p><img src="images/1a-modified-test-icon-preferences-530179.png" alt=""/></p>
<p>
Referenced projects can contain test sources and have test dependencies themselves. Usually, when test sources are
compiled, the test code in projects on the build path will be visible. As this is not always desirable, it can be
changed by setting the new build path attribute <b>Without test code</b>, that is available for projects, to <b>Yes</b>.</p>
<p><img src="images/2-without-test-code-526858.png" alt=""/></p>
<p>Build path entries configured like this have a decoration <code>[without test code]</code> after the project name,
which can be disabled in <b>Preferences > General > Appearance > Label Decorations</b>:</p>
<p><img src="images/2a-without-test-code-decorator-530179.png" alt=""/></p>
<p>For each project, compilation is now done in two phases: First all main sources (which cannot see any test-code on
the build-path) and then all test sources.</p>
<p><img src="images/3-visibilities-224708.png" alt=""/></p>
<p>As a consequence, if the project is a modular Java 9 project, test dependencies like JUnit can not be referenced in
the <code>module-info.java</code>, as they will not be visible while compiling it.
The solution used to handle this is the same, that Maven uses: When test dependencies are put on the classpath, the module being compiled will automatically be configured to read the unnamed module during the compilation of the test sources, so the test dependencies will be visible.</p>
<p>Of course, code completion will not suggest test code in main sources:</p>
<p><img src="images/4a-completion-in-main-521331.png" alt=""/></p>
<p><img src="images/4b-completion-in-test-521331.png" alt=""/></p>
<p>There are now two dynamic Java working sets <b>Java Main Sources</b> and <b>Java Test Sources</b> containing the source folders grouped according to value of the <b>Contains test sources</b> attribute. This can for example be used to remove warnings in test sources from the problems view:</p>
<p><img src="images/5a-problems-view-521336.png" alt=""/></p>
<p>To achieve this, create a new filter that shows warnings for the <b>Java Main Sources</b> working set and select it with the <b>All Errors on Workspace</b> filter:</p>
<p><img src="images/5b-problems-view-filters-521336.png" alt=""/></p>
<p>There are also dedicated filters to quickly remove hits in main code or test code from Java search results:</p>
<p><img src="images/6-filter-search-result-521332.png" alt=""/></p>
<p>Similar, there is a filter to remove test code from <b>Call hierarchies</b>:</p>
<p><img src="images/7-filter-call-hierarchy-521335.png" alt=""/></p>
<p>Another filter to remove test code exists for <b>Quick type hierarchies</b>:</p>
<p><img src="images/8-filter-quick-type-hierarchy-521333.png" alt=""/></p>
<p>Test source folders will be preselected in the <b>New JUnit Test Case</b>-Wizard</p>
<p><img src="images/9-new-junit-332602.png" alt=""/></p>
<p>In Run and Debug configurations, the <b>Classpath</b> tab (or <b>Dependencies</b> tab when launching with Java 9) contains a new option <b>Exclude Test Code</b>, that is automatically preselected when launching a Java Application from a source folder that is not marked to contain test sources:</p>
<p><img src="images/10-launching-529321.png" alt=""/></p>
<p>When launching with Java 9 and this option is not selected, command line options will automatically be added so modules that have a non-empty classpath read the unnamed module.
These command line options are part of what can be overridden using the new <a href="#override-dependencies">Override Dependencies</a> button.</p>
</td>
</tr>
<tr id="sort-library-entries-jdt">
<td class="title">Sort library entries alphabetically in Package Explorer</td>
<td class="content">
The content of libraries are displayed in the order of the classpath. This makes it difficult to find
specific libraries by their name, especially when projects have many dependencies. The library entries
can now be sorted alphabetically when setting the preference <b>Sort library entries alphabetically in Package Explorer</b>
on the <b>Java > Appearance</b> preference page:
<p><img src="images/jdt_sort_library_pref.png" alt=""/></p>
<table>
<tr><th>OFF</th><th>ON</th></tr>
<tr>
<td><img src="images/jdt_library_entries_unsorted.png" alt="before" style="width:240px"/></td>
<td><img src="images/jdt_library_entries_sorted.png" alt="before" style="width:240px"/></td>
</tr>
</table>
<p>The default for this preference is <b>OFF</b>.</p>
</td>
</tr>
<tr id="generate-dialogs-jdt">
<td class="title">Generate dialogs use verbs instead of OK</td>
<td class="content">
The <b>Generate...</b> dialogs of the Java tools have been adapted to use verbs instead of OK.
</td>
</tr>
<!-- ******************* Java Compiler ************************************* -->
<tr>
<td id="JavaCompiler" class="section" colspan="2">
<h2>Java Compiler</h2>
</td>
</tr>
<tr id="trapdoor-regex-module">
<td class="title">Option for Regex in Module Declaration Search</td>
<td class="content">
This is an <b>experimental</b> support provided to allow the regular expression usage in search field while searching for module declaration.
This can be considered as a wrapper of the <a href="#regex-module-declaration-search-api">API change</a>.
<p>
To invoke the regular expression search from the search field under Java Search, start the expression with "/r " i.e, a slash '/',
the letter 'r' and a blank ' ' (not tab)
followed by a regex, an example of which is shown below:
</p>
<p>
<img src="images/mod.regex.trap.png" alt="Trapdoor for regular expression module declaration search" />
</p>
<p>
In the above example, all the characters trailing "/r " form a Java regular expression to denote a module name which starts
with zero or more 'n's followed by the string ".ver" and followed again by zero or more number of arbitrary characters.</p>
<p>
Another example would be to search for all modules that start with <code>java.x</code> followed by zero or more
characters which is given by the regular expression <code>/r java\.x.*</code> -
note the backslash for . to consider this as a "normal" character instead of the special regex].
</p>
<p>
Yet another example would be search for all module names that start with j followed by zero or more characters and ending with .xml which in regex language
translates to <code>/r j.*\.xml</code>. Please note that here the first '.' is the special regex character while the second '.' is
escaped to denote that this is a normal character.
</p>
<b>Note:</b> You should use this only for <b>Declarations</b> search for modules as it is not implemented for module references. Selecting
<b>All occurrences</b> in conjunction with regex will default to finding only the Declarations matching the regex ignoring the references.
</td>
</tr>
<tr id="nonnullbydefault-per-module">
<td class="title">@NonNullByDefault per module</td>
<td class="content">
If a module is annotated with <code>@NonNullByDefault</code>, the compiler will interpret this
as the global default for all types in this module:
<code style="margin-left:20pt;color:#646464;">@org.eclipse.jdt.annotation.<strong>NonNullByDefault</strong></code><br/>
<code style="margin-left:20pt;"><strong style="color:#7F0055;">module</strong> my.nullsafe.mod { ...</code>
<p>Note, however, that this requires an annotation type declared either with target <code>ElementType.MODULE</code>,
or with no explicit target at all. Versions 2.2.0 and greater of bundle <code>org.eclipse.jdt.annotation</code>
use the latter strategy and hence support a module-wide non-null default.
</p>
</td>
</tr>
<tr id="nonnullbydefault-improvements">
<td class="title">@NonNullByDefault improvements</td>
<td class="content">
When using annotation-based null analysis, there are now more ways to define which unannotated locations are implicitly assumed to be annotated as <code>@NonNull</code>:
<ul>
<li>
<a href="http://help.eclipse.org/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/annotation/NonNullByDefault.html"><code>@NonNullByDefault</code></a>
annotations based on enum <a href="http://help.eclipse.org/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/annotation/DefaultLocation.html"><code>DefaultLocation</code></a>
can also be used if the primary nullness annotations are declaration annotations (previously this was supported only for <code>TYPE_USE</code> annotations).
</li>
<li>
Support for <code>@NonNullByDefault</code> annotations that are targeted at parameters has been implemented.
</li>
<li>
Multiple different <code>@NonNullByDefault</code> annotations (especially with different default values) may be placed at the same target,
in which case the sets of affected locations are merged.
</li>
<li>
Annotations which use a meta annotation <code>@TypeQualifierDefault</code>
instead of a <code>DefaultLocation</code>-based specification are now understood, too, e.g.
<a href="https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/lang/NonNullApi.html"><code>@org.springframework.lang.NonNullApi</code></a>.
</li>
</ul>
Version 2.2.0 of bundle <code>org.eclipse.jdt.annotation</code>
contains an annotation type <code>NonNullByDefault</code> that can be applied to parameter and
<a href="#nonnullbydefault-per-module">module declarations</a> (in addition to the previously allowed targets).
</td>
</tr>
<tr id="testsources-apt">
<td class="title">Test sources</td>
<td class="content">
There is now support for running Java annotation processors on <a href="#jdt-test-sources">test sources</a>.
The output folder for files generated for these can be configured in the project properties in
<b>Java Compiler > Annotation Processing</b> as <b>Generated test source directory</b>.
<p><img src="images/testsources-apt-531072.png" alt=""/></p>
</td>
</tr>
<tr id="jdt-complier-building-preference">
<td class="title">New preference added "Compiler Compliance does not match used JRE"</td>
<td class="content">
A new preference <b>Compiler Compliance does not match used JRE</b> is added to Compiler Preference Building Page.
<p>This preference indicates the severity of the problem reported when project's used JRE does not match the
compiler compliance level selected. (e.g. a project using JRE 1.8 as JRE System Library,
and the compiler compliance is set to 1.7).</p>
<p> The value of this preference is by default WARNING. </p>
<p> If the JRE being used is 9 or above and the <b>--release</b>
option is selected and even if the compiler compliance does not match the JRE being used, this option will be ignored.</p>
<p> This preference can be set as shown below: </p>
<p><img src="images/jdt_compiler_compliance_mismatch_JRE.png" alt=""/></p>
</td>
</tr>
<!-- ******************* Java Formatter ************************************* -->
<tr>
<td id="JavaFormatter" class="section" colspan="2">
<h2>Java Formatter </h2>
</td>
</tr>
<tr id="formatter-profile">
<td class="title">New formatter profile page</td>
<td class="content">
The formatter profile preference page <b>(Java &gt; Code Style &gt; Formatter &gt; Edit...)</b> has a new look which
makes it much easier to set preferences for formatting Java code. Instead of multiple tabs, all preferences are
presented in an expandable tree.
<p><img src="images/formatter-profile-overview.png" alt=""/></p>
<p>You can use <b>filtering</b> to display only the settings with names matching a specific phrase. Filtering by values is also
possible (prefix a value filter with a tilde).</p>
<p><img src="images/formatter-profile-filtering.png" alt="Example filtering by word 'lambda'"/></p>
<p>Most sections have a <b>Modify all</b> button in their header that lets you set all their preferences to the same value
with one click.</p>
<p><img src="images/formatter-profile-modify-all.png" alt=""/></p>
<p>Some preferences have more convenient controls. For example, number values can be easily modified with arrow buttons.
Wrap policy settings are controlled by simple toolbars so that you can see and compare multiple policies at once.</p>
<p><img src="images/formatter-profile-wrap-settings.png" alt=""/></p>
<p>In the preview panel you can now use your own code to immediately see how it will be affected by the modified settings.
You can also see the raw form of standard preview samples and make temporary modifications to them.</p>
<p><img src="images/formatter-profile-preview.png" alt="New buttons: 'View/edit raw code' and 'Custom preview contents'"/></p>
</td>
</tr>
<tr id="formatter-javadoc">
<td class="title">Formatter: align Javadoc tags in columns</td>
<td class="content">
The formatter can now <b>align names and/or descriptions</b> in Javadoc tags in new ways. The formatter profile editor is available for selection, under <b>Comments &gt; Javadoc</b>.
<p><img src="images/formatter-javadoc-prefs.png" alt=""/></p>
<p>For example, the <b>Align descriptions, grouped by type</b> setting is now used in the built-in Eclipse profile.</p>
<p><img src="images/formatter-javadoc-preview.png" alt=""/></p>
<p>The setting previously known as <b>Indent Javadoc tags</b> is now called <b>Align descriptions to tag width</b>. The two settings related to <b>@param tags</b> also had their labels changed to better describe what they do.</p>
</td>
</tr>
<tr id="formatter-dark-theme">
<td class="title">Java code formatter preferences now styled for the dark theme</td>
<td class="content">
The formatter preferences tree styling has been fixed to work properly in the dark theme.
</td>
</tr>
<tr id="jdt-remove-redundant-modifiers-cleanup">
<td class="title">New Cleanup Action "Remove redundant modifiers"</td>
<td class="content">
The new cleanup action "Remove redundant modifiers" removes unnecessary modifiers on types, methods and fields. The following modifiers are removed:
<ul>
<li>Interface field declarations: <code>public</code>, <code>static</code>, <code>final</code></li>
<li>Interface method declarations: <code>public</code>, <code>abstract</code></li>
<li>Nested interfaces: <code>static</code></li>
<li>Method declarations in final classes: <code>final</code></li>
</ul>
The cleanup action can be configured as save action on the <i>Unnecessary Code</i> page.
<p><img src="images/jdt_remove_redundant_modifiers.png" alt=""/></p>
</td>
</tr>
<!-- *********************** Debug ******************************** -->
<tr>
<td id="Debug" class="section" colspan="2">
<h2>Debug</h2>
</td>
</tr>
<tr id="prototype-java-launch-configuration">
<td class="title">Launch configuration prototypes for Java Launch Configurations</td>
<td class="content">
A Java Launch Configuration can now be based on a prototype.
<p>
<img src="images/prototype-java-launch-configuration.png" alt="Prototype Java Launch Configuration" />
</p>
A prototype seeds attributes in its associated Java Launch Configurations with the settings specified in the Prototype tab.
<p>
<img src="images/prototype-tab-java-launch-configuration-1.png" alt="Prototype Tab Java Launch Configuration 1" />
</p>
Once a Java Launch Configuration has been created, you can override any initial settings from the prototype.
You can also reset the settings of a Java Launch Configuration with the ones from its prototype. A Java Launch Configuration
maintains a link to its prototype, but is a complete stand-alone launch configuration that can be launched, exported, shared, etc.
<p>
<img src="images/prototype-tab-java-launch-configuration-2.png" alt="Prototype Tab Java Launch Configuration 2" />
</p>
</td>
</tr>
<tr id="advanced-source-lookup">
<td class="title">Advanced source lookup implementation</td>
<td class="content">
More precise <b>advanced</b> source lookup implementation, particularly useful when debugging applications that load classes dynamically at runtime.
<p>
New <code>org.eclipse.jdt.launching.workspaceProjectDescribers</code> extension point can be used to enable advanced source lookup for projects with non-default layout, like PDE Plug-In projects.
</p>
<p>
New <code>org.eclipse.jdt.launching.sourceContainerResolvers</code> can be used to download sources jar files from remote artifact repositories, like Maven Central or Eclipse P2.
</p>
<p>Advanced source lookup affects debug launches only and can be enabled or disabled with <b>Java > Debug > Use advanced source lookup (JRE 1.5 and higher)</b> preference option:</p>
<p><img src="images/advanced-source-lookup.png" alt=""/></p>
</td>
</tr>
<tr id="worker-deobfuscated-jdt">
<td class="title">Debugger listens to thread name changes</td>
<td class="content">
<b>Debug view</b> now automatically updates thread names if they are changed in the debuggee JVM.
This shows live information for worker instances, as described above.
<p>
Technically speaking, Java debugger automatically adds a new (user invisible) breakpoint in the JVM and notifies
clients (like Debug view) on a breakpoint hit. If this behavior is undesired for some reason, product owners can disable it via product customization.
</p>
<p>
The property value is:
<code>
org.eclipse.jdt.debug.ui/org.eclipse.jdt.debug.ui.javaDebug.ListenOnThreadNameChanges=false
</code>
</p>
</td>
</tr>
<tr id="method-result-and-exception-thrown">
<td class="title">Value displayed for method exit and exception breakpoints</td>
<td class="content">
When a <b>method exit breakpoint</b> is hit, the value being returned is now shown in the variables view.
<p>
<img src="images/returningvalue.png" alt=""/>
</p>
<p>
Similarly, when an <b>exception breakpoint</b> is hit, the exception being thrown is shown.
</p>
<p>
<img src="images/throwingexception.png" alt=""/>
</p>
</td>
</tr>
<tr id="debug-shell">
<td class="title">Display view renamed to Debug Shell</td>
<td class="content">
The <b>Display view</b> has been renamed to <b>Debug Shell</b> to better match the features and purpose of this view.
Also, a java comment is shown in the Debug Shell on fresh open that explains when and how to use it.
<p>
<img src="images/debugShell.png" alt="Debug Shell" />
</p>
</td>
</tr>
<!-- *********************** JDT Developers ******************************** -->
<tr>
<td id="JDTDev" class="section" colspan="2">
<h2>JDT Developers</h2>
</td>
</tr>
<tr id="dom-api-getbinding-change">
<td class="title">Package binding with recovery</td>
<td class="content">
The existing method <code>IBinding#getJavaElement()</code> now
accommodates recovered packages in which case a <code>null</code> may be
returned for such package bindings with problems. Pre-Java 9 compliant code
will continue to have a non-null return value for this API for packages.
</td>
</tr>
<tr id="regex-module-declaration-search-api">
<td class="title">Support for Regex Module Declaration Search</td>
<td class="content">
The existing method <code>SearchPattern#createPattern(String , int , int , int )</code> is enhanced for
supporting regular expression search for module declarations. Please note that the flag
<code>SearchPattern#R_REGEXP_MATCH</code> used for regular expression search is applicable exclusively for
module declarations. No other flag (for eg.<code>SearchPattern#R_CASE_SENSITIVE</code>) should be used in
disjunction with this match rule.
</td>
</tr>
</tbody>
</table>
<script type="text/javascript" src="scripts.js"></script>
<p style="text-align:center">
<a href="platform.php">Previous</a> <a style="margin:1em" href=".">Up</a> <a href="platform_isv.php">Next</a>
</p>
</body>
</html>