Eclipse SDK 4.31

What's new in this version:

New features in the Platform and Equinox:
Views, Dialogs and Toolbar:
Viewer Limit in Workbench:
- Several of the most commonly used Eclipse views have enabled incremental view updates. These views limit the initially-shown number of children to 1000 per parent element, and support incrementally displaying the next batch of elements. The increment number can be configured in the preferences under General > Initial maximum number of elements shown in views
- Other (3rd party) views can also read this preference to enable this feature for that view; this must be done explicitly for each view.
- The support for incremental view updates was added to avoid UI freezes in large viewers, where SWT/JFace approaches the limits of the underlying native widget machinery while trying to render many thousands of elements, leading to minute long UI freezes.

Incremental view update is currently enabled in the following views:
- Package Explorer
- Project Explorer
- Problems
- Java Outline
- JUnit
- This new preference can be disabled in products by specifying org.eclipse.ui.workbench/largeViewLimit=0 in the plugin_customization.ini file or via an Oomph preference task. In the same way, the preference value can be changed for products that need a lower or higher limit.

Filter Field for the Installation Details Dialog's Features Tab:
- Previously the Features tab of the Installation Details dialog, unlike the dialog's Plug-ins tab, did not provide a filter field. That inconsistency has been addressed, making it easier to find details about a specific feature.

Showing Resolved Workspace Path in Launch Dialog:
- A new feature has been implemented in the Eclipse launch dialog, which alerts the user that, the tilde (~) character, which usually refers to the user's home directory according to many operating system shell semantics, is unresolved whenever they enter that character. Additionally, this enhancement displays the resolved path within a label, offering user clear insight into the specified path.

Displaying Search Patterns in the Title Bar of Quick Search Dialogs:
- Distinguishing between the search patterns of concurrently open Quick Search dialogs was challenging, as they were all uniformly labeled as "Quick Search". A new functionality has been incorporated, wherein the search term is displayed alongside the "Quick Search" label in the title bar of the dialog. This enhancement ensures that each window is uniquely identifiable, now denoted as "Quick Search - " followed by the respective search term, thereby enhancing effortless navigation and improved user clarity.

Text Editors:
Compare Editor:
- The number of differences between two files is shown on the toolbar of compare editor; this is equal to the number of change markers shown next to the scroll bar in compare editor. This feature is helpful when the files compared are large and have many differences that cannot be counted manually.

Default Editor for a Content Type:
- For the case that there are multiple editors suitable to open a given content type, the user can declare one of these editors as default editor, i.e., the preferred editor. Simply select the editor in the associated editors list and press the Default button. If there is no default editor, the first suitable editor found is used to open the content type.

Themes and Styling:
Hovering Over Editor / View Tabs:
- When using the Light theme on macOS, the background color of unselected tabs now slightly changes color when the user hovers over them with the mouse cursor. The same hovering behaviour already exists on Windows and when using the Dark theme.

Highlighting of Active Part:
- The Light theme now also highlights the active part with a blue underline just like it was already done when using the Dark theme

Full Text in View Tabs:
- A new preference has been introduced to enhance the user experience for managing views. With this preference, users have more control over how view tabs are displayed.
- Previously, as the number of views increased within a view stack, the tab titles became very small, displaying only icons. This made it more challenging for users to identify views solely based on icons, sometimes leading to a cluttered UI and decreased usability.

To address this issue, two options are now available in the Tab icons and titles in view areas section on the General > Appearance preference page:
- Always show full titles: This option ensures that the full text of each view title is always visible in each tab, regardless of the number of views present. It improves usability by making it easier for users to identify views by label. By default this option is off.
- Hide icons: With this option selected, view icons are hidden, and only the full text of each view title is displayed in each tab. This helps in decluttering the UI and ensures that the editor area remains the focal point, especially in scenarios where numerous views are open. By default this option is off.

General Updates:
Eclipse Launcher Reloads Configuration Files on Restart:
- Previously when Eclipse was restarted using File > Restart or File > Switch Workspace as well as after installing or updating from a p2 update site, it restarted with same arguments as those in effect for the initial start. Any manual changes made to the eclipse.ini, as well as changes made by p2 touchpoints when installing or updating, were ignored. To actually apply the changes of a modified eclipse.ini, it was necessary to exit the application and restart it from the launcher.
- Now the Eclipse launcher is enhanced to reload the configuration files on restart, so any changes to the eclipse.ini take effect immediately. In addition, any command line arguments specified for the initial launch remain in effect on restart, except if the restart command contains --launcher.skipOldUserArgs.

New 'wires' Command in the OSGi Console:
- Previously it was quite challenging to determine if or why a certain bundle was using other bundles or was used by other bundles. There is now a new wires command that, for a specified bundle, prints all wires that are used by the bundle and any wires it provides to other bundles. This provides a powerful tool for analyzing dependency problems and for determining why a bundle is actually used.

Windows Defender Automatic Configuration:
- On Microsoft Windows 10 or later, the Microsoft Defender can significantly slow down the startup and overall performance of Eclipse-based applications. The Eclipse IDE can now detect if Microsoft Defender is active, inform the user about it and, if desired, can exclude itself from future Defender scans.
- On Windows the General > Startup and Shutdown preference page offers further information and allows the user to disable the startup check for new installations and to run the exclusion check again for the running installation.

Creators of custom Eclipse-based products that use the org.eclipse.ui.ide.workbench application and want to suppress the new startup check for their product can disable it by adding the following entry to their product's preferenceCustomization properties file:
- org.eclipse.ui/windows.defender.startup.check.skip=true

To execute the startup check for products that run applications other than org.eclipse.ui.ide.workbench add the entry:
- org.eclipse.ui/windows.defender.startup.check.app=

Improvement in Progress Bar Consistency and Smoothness:
- Previously in Eclipse, the progress bar did not accurately reflect the progress relative to the total time. Specifically, the initial half of the progress bar advanced rapidly, while a noticeable delay occurred in the latter half. This discrepancy was due to the utilisation of bundle-changed events for progress determination, which resulted in an uneven progression due to the non-uniform nature of these events.
- The progress is now determined as a function of the service level events occurring while the workbench is being bootstrapped. This gives more meaningful values about the progress the workbench has achieved towards completion. This modification has led to a more consistent and smooth advancement of the progress bar, leading to an overall improved user experience.

New features for Java developers:
Java Editor:
New Make Static Refactoring:
- A new refactoring called 'Make Static' has been added to Eclipse's Java Development Tools (JDT), which converts instance methods into static methods, when possible. This refactoring adds an extra parameter to the method declarations to handle references to instance fields, methods, or classes in the original method. Existing calls to the method are altered accordingly, and if the extra parameter is necessary, the refactoring passes 'this' or the specific instance originally used to access the method.

To apply this refactoring, the following conditions must be met:
- The method is not a constructor
- The method does not override a method from the parent type nor is overridden in any child types
- The type in which the method is declared is not a local type, an anonymous type, or an annotation
- The refactoring can be executed by selecting a method invocation, except in cases where a super method invocation is selected

Java Compiler:
Analysis of Resource Leaks Improved with Annotations:
- The compiler's capability to detect when resources (implementation of AutoCloseable) are not properly closed has been enhanced
- Previously, flow analysis for resource leaks was focused on resources that are created and closed within the same method. It could not deal well with resources that are shared between different methods, perhaps even different objects.

The compiler now interprets an annotation @Owning to understand data flows of resources by way of the following concepts:
- A source of resources
- Here a resource will come into the focus of the current method, along with a responsibility to close it
- A sink for resources
- Here a resource will be consumed, either by closing, or by delegation to other code which then will be responsible
- Resource allocation is the primordial source, and a call to AutoCloseable.close() is the final sink. When allocation and closing do not happen within the same method, then annotation @Owning should be used to create connections through which responsibility for a resource can be transferred from one method to another. The inverse annotation @NotOwning, on the other hand, signals that no such connection is made; the original holder of the resource is still responsible for sending it to a suitable sink.
- It's in method produce() where a new resource is allocated. The return statement in that method is governed by the @Owning annotation on the method. This implies that returning this value is a sink from the point of view of produce(). By this method produce() is considered safe. But looking from the outside this sink is in fact the source by which the resource arrives in method test().

After method test() receives the resource, the responsibility to close is fulfilled by passing it down into consume(). In method consume() it's the annotation on parameter in that creates the connection: test() has done its part and now consume() is responsible. Protecting the resource with a try-with-resources statement is the preferred way to fulfill the responsibility, its implicit close() call is the ultimate sink. Thus the given combination of method calls indeed creates a provably safe data flow from initial source to final sink, because both calls are governed by @Owning.
- The body of produce() also shows another detail: just like test() it passes the resource as a parameter to another method, here: skipHeader(). The parameter of skipHeader(), however, is annotated as @NotOwning by which the method rejects any responsibility. Indeed there's no close call to be found here, but that's OK under the @NotOwning annotation - this parameter is not a source. As a result, still after the call to skipHeader() it is produce() who is responsible. For that reason saying return in; is indeed necessary for produce() to demonstrate obedience to the contract.
- Additional rules exist for fields holding a resource and for methods other than close() that perform mandatory clean-up. Details on those can be found in the documentation of org.eclipse.jdt.annotation.Owning.
- To enable this feature select Java Compiler > Errors/Warnings > Enable annotation based resource analysis in the project preferences.

Java Formatter:
Switch Statements/Expressions: Align Arrows on Column:
- Switch statements and expressions with arrows can now be aligned so that all arrows are placed at the same position in line. Open the formatter profile editor and find the new option under Indentation > Align items in columns > Arrows in switch statements/expressions.

New APIs in the Platform and Equinox:
Platform Changes:
Viewer Limit in JFace:
- The API method org.eclipse.jface.viewers.ColumnViewer.setDisplayIncrementally(int incrementSize) was added to JFace. If incrementSize is set to some positive value, the viewer will initially show no more than this number of child elements per parent element. Additionally, the viewer provides a mechanism for a user to show more elements, if available, as needed. This API solves the problem with UI hangs in case a viewer tries to display a very large number of child elements per parent element.
- This feature is currently implemented in org.eclipse.jface.viewers.TableViewer and org.eclipse.jface.viewers.TreeViewer but is not enabled by default; incrementSize is 0 by default. Each concrete viewer implementation is responsible to enable this feature if needed.
- Note that even though this feature is designed to be backwards compatible API, there remains the possibility of regressions when converting existing viewer to use the new API. Please fully test your code when enabling this functionality!

Viewer Limit in Workbench:
- Complementary to the JFace API above, org.eclipse.ui.IWorkbenchPreferenceConstants and org.eclipse.ui.views.WorkbenchViewerSetup API's were added. This API provides default workbench preference access and a convenient way for viewers to use default workbench values without writing extra code to listen for preference changes.

Deprecation of Equinox Bundles:
The following Equinox bundles are deprecated for removal:
- org.eclipse.osgi.services
- Its content has been replaced by the official OSGi bundles published to Maven-Central and it only re-exports these org.osgi.service.* bundles. Consumers are already encouraged to replace their requirements on the bundle org.eclipse.osgi.services with imports of the actual required org.osgi.service.* packages. This allows the OSGi runtime to choose any suitable, available provider of the package.
- org.eclipse.equinox.device
- This implementation of the org.osgi.service.device service is not known to have any users and did not receive updates in the past. It is deprecated for removal from future releases without replacement. In case there are users after all, they can continue to use past releases, use an alternative implementation, or get in contact with the Equinox team.

New features for plug-in developers:
Dialogs, Wizards and Views:
Support for bnd Project Templates:
- In the 4.28 release there was support added for Automatic Manifest Generation, this is now enhanced to support bnd project templates, so you can easily create your own templates or create new projects with existing bnd templates.
- This will now create a new template project that can be used to create new projects based on that template

General:
Declarative Services Annotations 1.4 Support:
- PDE's Declarative Services Annotations support now supports the generation of DS 1.4. For details, read OSGi R7 Highlights: Declarative Services.

Classpath Fix for bnd Projects:
- Suppose that you have imported a project into the workspace that previously required Bndtools to function correctly and now you want make some small changes. Previously you would need to install Bndtools, configure it, and hope that it's compatible with the existing Eclipse installation. With the latest release of PDE, you can just go to the compilation problem and choose "Fix Project Setup..."
- This will present the option to add a Plug-in Dependencies Container
- Apply that fix and you will see the bnd-defined dependencies are resolved