# 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>