Skip to main content
Eclipse IDE, Photon Edition New and Noteworthy

Java™ development tools

Java™ 10 Support

Eclipse support for Java™ 10

Java™ 10 is here, and JDT supports it completely.

The Eclipse compiler for Java (ECJ) implements the new Java 10 language enhancement which is the support for local variable type inference (JEP 286).

Addition of Java 10 JRE

A Java 10 JRE is recognized by Eclipse for launching. It can be added from the Window > Preferences > Java > Installed JREs > Add…​ page. It can be added from the Package Explorer as well using the project’s context menu.


An option to set compiler compliance to 10 on a Java project is provided.


Support for var compilation

Eclipse supports compilation of var as shown below:


When the type of var cannot be inferred, it is flagged as a compiler error as expected. An example is shown below:


Code Completion for var

Code completion is offered at places where var is allowed.


Code completion of var is not offered at places where var is not allowed.


Hover over var shows the javadoc of the inferred type.


Quick Assist to convert from var to the appropriate type is provided.


Quick Assist to convert from type to var is provided.


Quick Fix to change project compliance and JRE to 10

A Quick Fix Change project compliance and JRE to 10 is provided to quickly change the current project to be compatible with Java 10.


Java™ 9 Support

Eclipse support for Java™ 9

Java™ 9 is here, and JDT supports it completely:


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.

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:


An existing non-modular Java project can be quickly converted to a module by creating a for that project. This feature can be availed once the project has been moved to compliance 9:


With Java 9 support, a library or a container can now be added to the module path as opposed to the classpath:


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 Is modular node (or using the Edit button while Is modular is selected):

On the Contents tab individual modules inside a container like JRE System Library 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.

Configuring the Contents of a module container

On the Details tab the encapsulation of given modules can be further influenced. The following example shows how module can be made to export one of its packages to the module of the current Java project:


Toggling Defines one or more modules (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.

Java search now includes a new search scope - Module:


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.

User can change the JRE of launch configuration and on the confirmation, the tab changes from "Classpath" to "Dependencies" or vice versa.


If Java project is modular and module is described in, most of the dependencies will be defined in the Modular Entries.


If Java project is not modular, most of the dependencies will be defined in the Classpath Entries.


A new Quick Fix is offered on import statements to fix issues that are reported due to missing module dependency

This Quick Fix is applicable if the project is a Java9 project and has a

The Quick Fix can be invoked from the editor:


Before the Quick Fix is applied the module-info file looks as below


After the Quick Fix is invoked, `` will be updated to include requires 'MODULE_NAME'


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 file.

This Quick Fix is applicable if the project is a Java9 project and has a file.

The Quick Fix can be invoked from the editor:


Before the Quick Fix is applied, the module-info file looks as below


After the Quick Fix is invoked, `` will be updated to include requires 'MODULE_NAME'


After the Quick Fix is applied, the required import statement is added to the file reporting error


A new Quick Fix is available when you have an unresolved type on service provider in a provides directive in 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.

This Quick Fix is applicable if the project is a Java9 project and has a file.

The Quick Fix can be invoked from the editor:


When the service is a class, the Quick Fix is proposed for creating a class.

When the service is an interface or an annotation, two Quick Fixes are proposed for creating a class or an interface.

New --release on the Java compiler preference page

A new option --release is available on the Java compiler preference page.

This option will be enabled only if the JRE being used is a Java 9 or above.

Workspace Preference:


Project Preference:


In the past, it was possible to compile for an older version of the Java language.

However, the compiler always compiled against the platform APIs that is found in the project’s build path.

For Example: 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.

The new --release compiler option now allows the user to configure compilation against a platform API version of user’s choice.

For Example: 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.

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

In the below picture, compliance is set to 1.5, therefore the --release option is disabled.


The --release option is enabled by default for all new projects created using JRE 9 or above.

Use --release option for Default Access rules and EE descriptor

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.

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.

Paste code in Package Explorer

You can now paste a snippet of code representing directly into a source folder to create a file. For example, copy this code:

import java.sql.Driver;
module hello {
    exports org.example;
    requires java.sql;
    provides Driver with org.example.DriverImpl;

Then, select a source folder in a Java 9 project in the Package Explorer view and use Ctrl+V (Edit > Paste) to paste it. This automatically creates a file in the source folder with the copied content.

Content assist for module declaration name

Content assist (Ctrl+Space) support is now available for module declaration name.


Quick Fix for unresolved module on module name in requires directive

A new Quick Fix is offered on requires statements in the 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.

This Quick Fix is applicable if the project is a Java 9 project and has a file

This Quick Fix can be invoked from the editor.


Before the Quick Fix is applied the classpath entries look as below:


After the Quick Fix is applied the classpath entries look as below:


Quick Fix for Non-existing or empty package on ` exports directive`

A new Quick Fix is available when you have a ` non-existing or an empty package` in an exports directive in file.

This Quick Fix is applicable if the project is a Java9 project or above and has a file.

The Quick Fix can be invoked from the editor:


A Quick Fix is provided to create either a Class, or an Interface or an Annotation or an Enum in the given package.

If the package does not exist, a new package is created and the new element is created in the package.

Creation of file on creation of a new Java9 Project

When creating a Java project with compliance Java 9 or above, a new option is offered for the creation of the file.

A new checkbox has been added in the Java Settings page (Page 2) of the New Java Project wizard. See images below.

Page 1:


Page 2:


The new checkbox for the creation of file is checked by default.

When this checkbox is checked, upon project creation, the dialog for creation of a new ` ` file will appear.


Selecting Don’t Create in the above dialog does not create the file, but creates the project.

Overriding modular build path dependencies for launching

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. Override Dependencies button has been added to Dependencies tab:

Override Dependencies button

Dialog can be used to override modular dependencies:

Override Dependencies dialog


Eclipse support for JUnit 5.1

JUnit 5.1 is here and Eclipse supports it.

Create a new JUnit Jupiter test via New JUnit Test Case wizard:


Add JUnit 5 library to the build path:

  • New JUnit Test Case wizard offers to add it while creating a new JUnit Jupiter test:


Quick Fix (Ctrl+1) proposal on @Test, @TestFactory, @ParameterizedTest and @RepeatedTest annotations:


Add JUnit library in Java Build Path dialog:


Create a JUnit Jupiter test method with the new test_jupiter template:


Create a @TestFactory method with the new test_factory template:


JUnit Jupiter’s Assertions, Assumptions, DynamicContainer and DynamicTest classes are now added to Eclipse Favorites by default:


This allows you to quickly import the static methods from these classes in your code via Content Assist (Ctrl + Space) and Quick Fix (Ctrl + 1).

View all the failures from grouped assertions in the same Result Comparison dialog opened from JUnit view:


View the number of disabled tests and tests with assumption failures on hover in JUnit view:


Use Go to File action or just double-click to navigate to the test from JUnit view even when the test is displayed with a custom name:


(Re-)Run a single @Nested test class by using the Run action in JUnit view or Outline view. You can even right-click on a nested test class name in the editor and use the Run As action:


The Test Method Selection dialog in JUnit launch configuration now shows the method parameter types also:


You can provide tags to be included in or excluded from a test run in the Configure Tags dialog of JUnit launch configuration:


In JUnit Jupiter, a method parameter of type TestReporter can be used to publish additional data about the current test run which can be viewed in the Console view:


If you are using an Eclipse workspace where you were running your JUnit 5 tests via @RunWith(JUnitPlatform.class) 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:


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 (org.eclipse.jdt.junit.runtime, org.eclipse.jdt.junit4.runtime) 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.

Java Editor

Quick Fix to add @NonNullByDefault to packages

A new Quick Fix is offered to fix issues that are reported when the Missing '@NonNullByDefault' annotation on package warning is enabled.

If the package already has a, the Quick Fix can be invoked from the editor:


Otherwise, the Quick Fix must be invoked from the problems view, and will create a with the required annotation:


When invoked from the problems view, both variations of the Quick Fix can fix the problem for multiple packages simultaneously.

You can now Ctrl+click or use Open Declaration (F3) on case or default keywords to quickly navigate to the beginning of the switch statement.


Escape non-ASCII characters when pasting into a string literal

The Java > Editor > Typing > Escape text when pasting into a string literal preference option now has a suboption Use Unicode escape syntax for non-ASCII characters:


When enabled, characters outside the visible ASCII range will be replaced by unicode escape sequences when pasted into a string:


Improved Java syntax coloring in the dark theme

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.


Improved coloring of inherited members in the Quick Outline in the dark theme

The Eclipse default dark theme now includes styling of inherited members in JDT’s Quick Outline. This improves readability in the dark theme a lot. The color can be configured via the Java > Inherited Members color definition on the Colors and Fonts preference page.





Java Views and Dialogs

Test sources

In the Java Build Path project settings, there is now an attribute Contains test sources 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 Visible only for test sources. This setting also exists for classpath containers, and if it is set to Yes for one of these, this value will be used for all contained libraries and projects.


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 Preferences > Java > Appearance:


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 Without test code, that is available for projects, to Yes.


Build path entries configured like this have a decoration [without test code] after the project name, which can be disabled in Preferences > General > Appearance > Label Decorations:


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.


As a consequence, if the project is a modular Java 9 project, test dependencies like JUnit can not be referenced in the, 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.

Of course, code completion will not suggest test code in main sources:


There are now two dynamic Java working sets Java Main Sources and Java Test Sources containing the source folders grouped according to value of the Contains test sources attribute. This can for example be used to remove warnings in test sources from the problems view:


To achieve this, create a new filter that shows warnings for the Java Main Sources working set and select it with the All Errors on Workspace filter:


There are also dedicated filters to quickly remove hits in main code or test code from Java search results:


Similar, there is a filter to remove test code from Call hierarchies:


Another filter to remove test code exists for Quick type hierarchies:


Test source folders will be preselected in the New JUnit Test Case-Wizard


In Run and Debug configurations, the Classpath tab (or Dependencies tab when launching with Java 9) contains a new option Exclude Test Code, that is automatically preselected when launching a Java Application from a source folder that is not marked to contain test sources:


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 Override Dependencies button.

Sort library entries alphabetically in Package Explorer

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 Sort library entries alphabetically in Package Explorer on the Java > Appearance preference page:






The default for this preference is OFF.

Generate dialogs use verbs instead of OK

The Generate…​ dialogs of the Java tools have been adapted to use verbs instead of OK.

Java Compiler

This is an experimental 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 API change.

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:

Trapdoor for regular expression module declaration search

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.

Another example would be to search for all modules that start with java.x followed by zero or more characters which is given by the regular expression /r java\.x.* - note the backslash for . to consider this as a "normal" character instead of the special regex].

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 /r j.*\.xml. Please note that here the first '.' is the special regex character while the second '.' is escaped to denote that this is a normal character.


You should use this only for Declarations search for modules as it is not implemented for module references. Selecting All occurrences in conjunction with regex will default to finding only the Declarations matching the regex ignoring the references.

@NonNullByDefault per module

If a module is annotated with @NonNullByDefault, the compiler will interpret this as the global default for all types in this module: @org.eclipse.jdt.annotation.NonNullByDefault
module my.nullsafe.mod { …​

Note, however, that this requires an annotation type declared with target ElementType.MODULE. Since the annotation bundle org.eclipse.jdt.annotation is still compatible with Java 8, it cannot yet declare this target. In the interim, a preview version of this bundle with support for modules will be published by other means than the official SDK build.

@NonNullByDefault improvements

When using annotation-based null analysis, there are now more ways to define which unannotated locations are implicitly assumed to be annotated as @NonNull:

  • @NonNullByDefault annotations based on enum DefaultLocation can also be used if the primary nullness annotations are declaration annotations (previously this was supported only for TYPE_USE annotations).

  • Support for @NonNullByDefault annotations that are targeted at parameters has been implemented.

  • Multiple different @NonNullByDefault annotations (especially with different default values) may be placed at the same target, in which case the sets of affected locations are merged.

  • Annotations which use a meta annotation @TypeQualifierDefault instead of a DefaultLocation-based specification are now understood, too, e.g. @org.springframework.lang.NonNullApi.

Version 2.2.0 of bundle org.eclipse.jdt.annotations containing an annotation type NonNullByDefault that can be applied to parameter and module declarations (in addition to the previously allowed targets).

Test sources

There is now support for running Java annotation processors on test sources. The output folder for files generated for these can be configured in the project properties in Java Compiler > Annotation Processing as Generated test source directory.


New preference added "Compiler Compliance does not match used JRE"

A new preference Compiler Compliance does not match used JRE is added to Compiler Preference Building Page.

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).

The value of this preference is by default WARNING.

If the JRE being used is 9 or above and the --release option is selected and even if the compiler compliance does not match the JRE being used, this option will be ignored.

This preference can be set as shown below:


Java Formatter

New formatter profile page

The formatter profile preference page (Java > Code Style > Formatter > Edit…​) 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.


You can use filtering to display only the settings with names matching a specific phrase. Filtering by values is also possible (prefix a value filter with a tilde).

Example filtering by word 'lambda'

Most sections have a Modify all button in their header that lets you set all their preferences to the same value with one click.


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.


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.

New buttons: 'View/edit raw code' and 'Custom preview contents'

Formatter: align Javadoc tags in columns

The formatter can now align names and/or descriptions in Javadoc tags in new ways. The formatter profile editor is available for selection, under Comments > Javadoc.


For example, the Align descriptions, grouped by type setting is now used in the built-in Eclipse profile.


The setting previously known as Indent Javadoc tags is now called Align descriptions to tag width. The two settings related to @param tags also had their labels changed to better describe what they do.

Java code formatter preferences now styled for the dark theme

The formatter preferences tree styling has been fixed to work properly in the dark theme.

New Cleanup Action "Remove redundant modifiers"

The new cleanup action "Remove redundant modifiers" removes unnecessary modifiers on types, methods and fields. The following modifiers are removed:

  • Interface field declarations: public, static, final

  • Interface method declarations: public, abstract

  • Nested interfaces: static

  • Method declarations in final classes: final

The cleanup action can be configured as save action on the Unnecessary Code page.



Launch configuration prototypes for Java Launch Configurations

A Java Launch Configuration can now be based on a prototype.

Prototype Java Launch Configuration

A prototype seeds attributes in its associated Java Launch Configurations with the settings specified in the Prototype tab.

Prototype Tab Java Launch Configuration 1

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.

Prototype Tab Java Launch Configuration 2

Advanced source lookup implementation

More precise advanced source lookup implementation, particularly useful when debugging applications that load classes dynamically at runtime.

New org.eclipse.jdt.launching.workspaceProjectDescribers extension point can be used to enable advanced source lookup for projects with non-default layout, like PDE Plug-In projects.

New org.eclipse.jdt.launching.sourceContainerResolvers can be used to download sources jar files from remote artifact repositories, like Maven Central or Eclipse P2.

Advanced source lookup affects debug launches only and can be enabled or disabled with Java > Debug > Enable advanced source lookup preference option:


Debugger listens to thread name changes

Debug view now automatically updates thread names if they are changed in the debuggee JVM. This shows live information for worker instances, as described above.

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.

The property value is: org.eclipse.jdt.debug.ui/org.eclipse.jdt.debug.ui.javaDebug.ListenOnThreadNameChanges=false

Value displayed for method exit and exception breakpoints

When a method exit breakpoint is hit, the value being returned is now shown in the variables view.


Similarly, when an exception breakpoint is hit, the exception being thrown is shown.


Display view renamed to Debug Shell

The Display view has been renamed to Debug Shell 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.

Debug Shell

JDT Developers

Package binding with recovery

The existing method IBinding#getJavaElement() now accommodates recovered packages in which case a null 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.

The existing method SearchPattern#createPattern(String , int , int , int ) is enhanced for supporting regular expression search for module declarations. Please note that the flag SearchPattern#R_REGEXP_MATCH used for regular expression search is applicable exclusively for module declarations. No other flag (for eg.SearchPattern#R_CASE_SENSITIVE) should be used in disjunction with this match rule.

Java Code Coverage

Filters and support for Java 10

Various compiler generated artifacts, which previously required unnecessary and sometimes impossible tricks to not have partial or missed coverage, are now filtered out:

coverage finally
coverage try with resources

PHP Development Tools


Unused/unassigned variable validation support

pdt60 variable validator

Validation for scalars in break / continue

pdt60 break validator

Static operation validation for PHP >= 7

pdt60 const validator

Fixed support for ASP tags

pdt60 asp tags

PHP Explorer was replaced by Project Explorer

pdt60 perspective


  • Support "@param callback" in same way as "@param callable"

  • Open type shortcuts work in PHP perspective without focus on PHP editor


  • Async code completion

  • Improved code assist for @var tags

  • Fixed highlighting for projects with duplicated classes in validation paths

  • Fixed memory leak in PHP editors

  • Improved superglobal highlighting

  • Fixed highlighting for parent keyword

  • Method overriding support PHP 7 return types

  • Consistent tooltip for constants defined via define and const keywords

  • Improved highlighting for try/catch/finally statement


  • Formatter preferences always use latest supported PHP version

  • Support braces configuration for traits

  • Stable formatter results

  • No more "double spaces" around expressions

  • New "Line Wrapping" becomes "Keep trailing comma"

  • Formatter no longer produce "TextEdits" in places where code isn’t really touched


  • Fix possible deadlock during Xdebug session startup

  • Support Xdebug profiling. Via CLI Launch or manual CacheGrind file import

pdt60 profiling import
pdt60 profiling dash
pdt60 profiling tree
pdt60 profiling invocation
pdt60 profiling stat



Improved Tree and Table widget scaling at high DPI on Windows

Trees and Tables scale Checkboxes and expand/collapse buttons properly.

Tree widget image before and after

Dropped support for Windows XP

Eclipse/SWT has dropped support for the Windows XP Operating System and other Windows versions older than Windows Vista. Microsoft support for Windows XP, including security updates, ended in April 2014 and Windows XP has not been listed as a target environment for the Eclipse Platform for several years.


Improved readability of default text font on macOS

Reading the source code is the task developers perform the most during coding. So text editors must assist the user as good as possible with that.

On macOS Eclipse Photon now uses the "Menlo" font as the default text font, which does also contain bold font faces. This increases readability in source code editors using bold font faces:


Dark buttons on Mac

The background color of a button can now be styled on the Mac. This is used to style the buttons in the dark theme.


Animated waiting cursor on macOS

During long taking UI actions the cursor switches to a waiting cursor. On macOS this used to be a static black/white circle. From Eclipse Photon the macOS system’s busy cursor is changed to a spinning blue ball (also called beach ball).



Improved caret performance on GTK3

Caret performance on the SWT GTK3 port has been enhanced to allow for smoother drawing. Previously the caret stuttered when moved or when other controls in the same shell were manipulated. Now the caret moves smoothly and blinks at a consistent rate.

Accessibility support on GTK3

Significant improvements have been made in the Accessibility support on the SWT Linux/GTK3 port. Users are able to use assistive technologies seamlessly with SWT GTK3, just as they were able to with GTK2, and without any hangs or crashes.

GTK_THEME override support for SWT-GTK3

Eclipse SWT on GTK3.14+ now supports the use of GTK_THEME as an environment variable. SWT applications are correctly styled when using the GTK_THEME environment variable to override the system theme, and/or specify a dark variant. Below are the before and after screenshots of ControlExample running with GTK_THEME=Adwaita:dark set.





Improved memory usage on SWT-GTK3

Eclipse SWT on GTK3 has reduced memory usage after resolving a memory leak in setBackground/setForeground Color machinery. The leak was approximately 50MB/hour and affected clients running SWT on GTK3.14+.


Manage associations of content types with editors

The Content Types preference page was extended to allow to view, create and remove associations with editors.


Using the content type to define editor association is to be preferred over using the File Associations preferences.

Associate content type with a file name pattern

From the Preferences > General > Content Types preference page, you can now associate a content type with a file name pattern and use ? or * wildcards at any place in that pattern (respectively to match any character or any string).


Browser Editor can toggle auto-refresh

The Browser Editor now contains a drop down option for enabling auto-refresh for local pages. When enabled, the Browser Editor will automatically refresh if the opened file is edited and saved.


CodeMining support with SourceViewer

A code mining represents a content (ex: label, icons) that should be shown along with source text, like the number of references, a way to run tests (with run/debug icons), etc. The main goal of code mining is to help developer to understand more the written/writing code

A code mining is represented by org.eclipse.jface.text.codemining.ICodeMining which are provided by org.eclipse.jface.text.codemining.ICodeMiningProvider The org.eclipse.jface.text.source.ISourceViewerExtension5 provides the capability to register org.eclipse.jface.text.codemining.ICodeMiningProvider and update code minings.

The example CodeMiningDemo draws classes references / implementations code minings:


Detach view or editor via its context menu

You can now detach a view or an editor via its context menu.


Dark Theme

Improved text operation icons for the dark theme

The block selection, word warp and show whitespace icons have been adjusted to look good in the dark theme.





Improved popup dialogs for the dark theme

Popup dialogs as for example the platform’s update notification popup now uses a dark background and a light foreground color in the dark theme.

Update dialog in dark theme

Improved text color in text editor for the dark theme

The text editor now uses an improved font color in the dark theme so that you can read better.


The colors of links in code element information controls now take the color settings of the "Hyperlink text color" and the "Active hyperlink text color" from the "Colors & Fonts" preference page into account. The readability in the dark theme has been improved a lot by this.





Improved the text editor’s expand and collapse nodes for the dark theme

The collapse and expand nodes in the text editor’s left hand side ruler were improved for the dark theme.

old and new version of the icons

Improved the generic editor’s mark occurrences annotation color for the dark theme

The occurrences annotation marker color in the generic editor’s left hand side ruler were improved for the dark theme. Image is zoomed for better visibility.

old and new version of occurrence annotation

Canvas elements are styled in the default dark theme

The default dark theme now contains CSS for styling Canvas elements by default.





Links now consistently use a light blue color in the dark theme. One example where this was very visible is PDE’s manifest editor:

PDE's mantifest editor showing before and after


Open resource dialog highlights matching characters

The matching characters from the filter are now highlighted in the Open Resource dialog.


Import/export preferences from preference dialog

Easily accessible buttons for opening the Import/Export preferences wizards have been added to the lower left corner of the Preferences dialog. The wizards are still accessible through the File > Import…​ and File > Export…​ wizards.


Expanded Highlighting in Open Resource Dialog

The Open Resource dialog now shows you how the search term matches the found resources by highlighting the names based on camel-case and pattern ( * and ? ) searches.


Undo/Redo Toolbar Buttons

The main toolbar can now show Undo and Redo buttons.


The buttons are not available by default. They can be added via Window > Perspective > Customize Perspective…​:


QuickAccess matches Preference pages by keyword

QuickAccess (Ctrl+3) now also returns Preference pages that have a keyword matching user input.


Perfect matches appear first in selection dialogs

Within selection dialogs, including Open Type and Open Resource, perfect matches appear as the first result, ensuring that users no longer have to scroll through historical matches and the alphabetically sorted list to find their desired result.


Delete nested projects

The Delete Resources dialog now shows a Delete nested projects option to delete all projects whose location on file system is a descendant of one of the selected projects.


Debug perspective layout changed

Default Debug perspective layout changed, see screenshot below. The aim is to give the editor area more space and to show more relevant information without scrolling. Display view, Expressions view and Project Explorer are now shown by default, Problems view replaces Tasks.


Workers use job names as thread names

The jobs framework now uses Job names for Worker thread names. Previously all running Worker’s got enumerated thread names, without any hint what the current `Worker is actually doing:

Worker names before M5

Now the Job name is added next to the Worker name:

Worker names after M5

Right click option to export Launch Configurations

The Export Launch Configurations Wizard is now accessible through the right click menu on Launch Configurations. This wizard is still available with File > Export > Run/Debug > Launch Configurations


Flat layout in tabbed properties view

In the light theme the tabbed properties view now completely uses the same flat styling as the form-based editors do.


Open/Close Projects by Working Set in Project Explorer

The ability to Open, Close, Close Unrelated, and Build all appropriate projects in a Working Set has been added to the right click menu of Working Sets in the Project Explorer.


Modify project natures

The Project Properties dialog now features a page to add or remove natures on a project.


As mentioned on the page, some natures may not properly handle manual addition/removal, so using this can lead to some inconsistencies in those cases.

Possibility to configure the color of text editor’s range indicator

The text editor’s range indicators’s color can now be configured via the Colors and Fonts preference page.

Range indicator in the Colors and Fonts preference page

Styling for text editor’s range indicator

The Eclipse default dark theme now includes styling for the text editor’s range indicator.

Range indicator in the dark theme

Allow workspace to build projects in parallel

The Workspace preference page now has a new option to allow the workspace to build projects in parallel:

preference page screenshot

Under some safe circumstances, the workspace can now choose to build independent projects in parallel. In such case, the maximum amount of jobs/threads that will be running builds in parallel will be controlled by this preference. A value of 1 will indicate that build won’t be parallelized keeping the legacy behavior.

The optimal value will depend on the machine and workspace projects specificities. Recommendation is to try relatively low values (such as 4) first which will allow to save time, when allowed by projects, while not risking the CPU overload.

Refresh on access on by default

For years the Eclipse IDE is shipping with a customization that files are automatically refreshed if the user accesses them. Other Eclipse based tools like the Spring Tools Suite were missing this customization, so now they do not have to manually instruct their IDE to see the update.

Open resource dialog always shows the paths

You can now use the Open Resource dialog to see the file paths. Previously it only showed the paths if there were duplicate entries.


Improved the generic editor’s mark occurrences annotation label

The occurrences annotation marker label has been improved to show the word occurring rather than the line. In the image below, see the difference between old label at the top and the new one at the bottom.

old and new version of occurrence annotation

Open Source Projects

The following Eclipse open source projects participated in this release.


Eclipse is a trademark of the Eclipse Foundation. Java is a registered trademark of Oracle.

Back to the top