Adopting 4.12 mechanisms and APIs

This section describes changes that are required if you are trying to change your 4.11 plug-in to adopt the 4.12 mechanisms and APIs.

1. Removal of the org.eclipse.ecf.filetransfer.httpclient4 and org.eclipse.ecf.filetransfer.httpclient4.ssl features
2. Direct usages of IBM ICU4j should be upgraded

1. Removal of the org.eclipse.ecf.filetransfer.httpclient4 and org.eclipse.ecf.filetransfer.httpclient4.ssl features

What is affected: Clients including either of the above mentioned features from the 4.11 target platform.

Description: Since the Eclipse Platform migrated to the new ECF filetransfer implementation provided by the org.eclipse.ecf.filetransfer.httpclient45 feature, the following two features are no longer included in the Eclipse 4.12 target platform:

• org.eclipse.ecf.filetransfer.httpclient4
• org.eclipse.ecf.filetransfer.httpclient4.ssl

Action required: Clients are recommended to remove the org.eclipse.ecf.filetransfer.httpclient4 and org.eclipse.ecf.filetransfer.httpclient4.ssl features from their products if they are included directly and instead consume the new org.eclipse.ecf.filetransfer.httpclient45 feature.

Alternatively: Clients may also continue to use the old ECF features by consuming them directly from the ECF p2 repository instead of from the Eclipse Platform itself.

2. Direct usages of IBM ICU4j should be upgraded

What is affected: Clients directly using IBM ICU4j bundle versions earlier than 64.2.0.

Description: The IBM ICU4j bundles used by Eclipse Platform was updated to version 64.2.0 to take advantage of support for Unicode version 12 and to support the Japanese era. Clients that were making direct use of the IBM ICU4j APIs should upgrade and ensure their code continues to work with version 64.2.0. Other clients should not be affected. See IBM ICU4j website for details.

Action required: Clients should:

• Upgrade their products and code to work with IBM ICU4j version 64.2.0

3. Wizards can now be nonmodal

We have introduced new API to WizardDialog to enable a wizard to be nonmodal.

Description: When a dialog is modal it means that the underlying window can not be used. Eclipse Wizard Dialogs are modal by default. There are cases where it is desired that the dialog is not modal but that the underlying window can be reached WHILE the user is finishing the wizard. The following API methods are added to the JFace WizardDialog.

• public WizardDialog setModal(boolean modal)
• public boolean isModal()

In addition the following methods have been made public to allow full control over the shell style of the WizardDialog.

• public void setShellStyle(int newShellStyle)
• public int getShellStyle()

4. Direct usages of Apache Batik should be upgraded

What is affected: Clients directly using Apache Batik bundle versions earlier than 1.11.0.

Description: The Apache Batik bundles used by Eclipse Platform was updated to version 1.11.0 to take advantage of latest bugfixes and Java 11 compatibility. This updated included update of org.apache.xmlgraphics bundle to version 2.3.0 too. Clients that were making direct use of the Apache Batik APIs should upgrade and ensure their code continues to work with version 1.11.0. Other clients should not be affected.

Action required: Clients should:

• Upgrade their products and code to work with Apache Batik version 1.11.0

5. Pre-built Lucene indexes should be updated

What is affected: Clients supplying pre-built Lucene help indexes.

Description: We have updated the Apache Lucene search engine to Lucene 8.0.0. This means that the indexes built with older versions will not be readable anymore. See Lucene Change Log for details.

Action required: Clients should:

• Re-build their indexes with Lucene 8.0.0 and supply them as before>