Platform

Dropped support for Windows XP Eclipse/SWT has dropped support for the Windows XP Operating System and other Windows versions older than Windows Vista. For more information, please read the announcement made by the Eclipse PMC.

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.

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.

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.

Canvas elements are styled in the default dark theme The default dark theme now contains CSS for styling Canvas elements by default. Old: New:

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

Improved Tree and Table widget scaling at high DPI on Windows Trees and Tables scale Checkboxes and expand/collapse buttons properly.

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. Before:

After:



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

Ant 1.10.3 Eclipse has adopted Ant version 1.10.3.

JDT

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.

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.

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.

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 module-info.java file. This quick fix is applicable if the project is a Java9 project or above and has a module-info.java 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.

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.

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.

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 indicate 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:

Platform Developers

Support 'enabledWhen' for the all Generic Editor extension points All extension points targeting the Generic Edtor ( autoEditStrategies , contentAssistProcessors , highlightReconcilers , hoverProviders , presentationReconcilers , reconcilers ) now allows an enabledWhen child elements for contributions. This enableWhen is a Core Expression that controls whether the declared extension is enabled when insantiating the editor. The evaluation context defines extra variables you can use in the expression: viewer , editor and editorInput . This example shows how LSP4E contributes server highlight reconciler only for editor input supporting a language server: <extension point="org.eclipse.ui.genericeditor.highlightReconcilers"> <highlightReconciler class="org.eclipse.lsp4e.operations.highlight.HighlightReconciler" contentType="org.eclipse.core.runtime.text"> <enabledWhen> <with variable="editorInput"> <test property="org.eclipse.lsp4e.hasLanguageServer"> </test> </with> </enabledWhen> </highlightReconciler> </extension>

New API Monitor#getZoom() added A new API Monitor.getZoom() has been added which returns the zoom value used by SWT for the Monitor. The zoom value returned by the API is the zoom used by SWT that is controlled by the swt.autoScale property. It may not be the same value as that is set in the system. It can be used in other SWT APIs that require zoom as an input such as Image.getImageData(zoom) to get the ImageData at the zoom level for the specific Monitor on which it'll be drawn. There are two use-cases of the API: When the DPI of the monitor changes dynamically, the API can be used to return the new DPI.

On platforms that support a multi-monitor setup where different monitors can have different DPIs, the API can be used to get the DPI of the specific monitor on which a Control is drawn.

JDT Developers