Несовместимости между версиями Eclipse 3.0 и 3.1

Изменения между Eclipse версий 3.0 и 3.1 повлекли за собой некоторые несовместимости, касающиеся модулей. Ниже приведено описание измененных областей и инструкции по миграции модулей версии 3.0 в 3.1. Обратите внимание, что этот раздел будет полезен только в том случае, если модули 3.0 выполняются в версии 3.1 с ошибками.

  1. Параметры модуля
  2. Изменения ограничений IPath
  3. Реестр расширений
  4. Параметры программы форматирования исходного кода
  5. Изменения контракта API для AntCorePreferences
  6. Изменения контракта API для класса Policy в JFace
  7. Изменения контракта API, разрешающие пустую проекцию по умолчанию
  8. Изменения контракта API для IViewLayout
  9. Изменения контракта API для IVMInstall
  10. SelectionEnabler.SelectionClass доступен для пакета
  11. ContributionItem.getParent() может возвращать нулевое значение
  12. Изменения в isPropertySet(boolean) для IPropertySource и IPropertySource2
  13. элемент handlerSubmission удален из точки расширения org.eclipse.ui.commands
  14. Статическое неокончательное поле API GLOBAL_IGNORES_CHANGED в TeamUI сделано окончательным
  15. ClassCastException с помощью FillLayout
  16. Создание виджета с освобожденным родителем

1. Параметры модуля

Затронутые компоненты: Модули, инициализирующие свои значения параметров по умолчанию путем переопределения Plugin#initializeDefaultPreferences или использующие обработчики изменений параметров.

Описание: В Eclipse 3.1 объект org.eclipse.jface.preference.IPreferenceStore, полученный из org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore, перенесен поверх среды параметров Eclipse 3.0, предоставленной модулем org.eclipse.core.runtime.

Требуемое действие: В результате клиенты, применяющие API параметров, должны учитывать следующие несовместимости:

  1. Тип объектов, содержащихся в событиях изменения параметров, не гарантирован; старые и новые значения могут быть пустым объектом, объектом String или типизированным объектом. Таким образом, обработчики изменений параметров должны поддерживать все указанные типы значений.
  2. Если модуль использует org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences, то в список требуемых модулей следует добавить org.eclipse.core.runtime.compatibility, поскольку эта зависимость была удалена из модуля org.eclipse.ui.workbench.

Дополнительная информация приведена в документации по хранилищу параметров.

2. Изменения ограничений IPath

Затронутые компоненты: Модули, создающие и сохраняющие объекты IPath, а также управляющие ими.

Описание: В Eclipse 3.0 для сегментов путей IPath были указаны ограничения более жесткие, чем ограничения базовой операционной системы. А именно:

Данные ограничения отсутствуют в Eclipse 3.1, поскольку расположение данных платформы (рабочая область) принадлежит файловой системе, в которой подобные ограничения отсутствуют.

Требуемое действие: Для правильной обработки расширенных путей следует обновить все элементы Path и IPath, указанные в модулях, в соответствии со следующими инструкциями. Большинство неизмененных модулей будут работать также как в версии 3.0, если в них указаны пути, допустимые в 3.0. Однако применение в таких модулях путей, допустимых в 3.1, но недопустимых в 3.0, может привести к возникновению ошибок.

Модули, хранящие представления путей в виде строк в формате, поддерживаемом разными платформами, следует перенести в новый метод фабрики Path.fromPortableString. Этот метод преобразует платформонезависимый формат в экземпляр IPath. Представление пути в виде строки можно создать с помощью метода IPath.toPortableString. Примеры файлов мета-информации: файлы, входящие в состав проектов рабочей области Eclipse (.project, .classpath и т.д.), а также все файлы из хранилища параметров (org.eclipse.core.runtime.preferences.IPreferencesService).

Примечание: fromPortableString правильным образом считывает все строки путей, созданные с помощью метода Eclipse 3.0 IPath.toString, однако не поддерживает результаты метода Eclipse 3.1 toString. Таким образом, в большинстве случае не требуется вносить изменения в существующие форматы файлов мета-информации. Достаточно только начать создавать пути с помощью toPortableString и считывать их с помощью fromPortableString.

Модули, создававшие пути с помощью жестко закодированных символов, в которых предполагалось специальное назначение символов ':' и '\' на всех платформах, потребуется мигрировать. Наиболее простое решение - ограничить символы пути подмножеством, поддерживаемым на всех платформах (избегайте двоеточия и обратной черты). Символы пути могут поддерживать полный набор допустимых путей Unix, используя переносимый формат пути Path.toPortableString. Этот формат рассматривает первое одинарное двоеточие (':') в качестве разделителей устройств, косую черту ('/') - как разделитель сегментов, а двойное двоеточие - как литеральное двоеточие ("::"). Например, с помощью кода new Path("c:/temp") в платформах Unix теперь можно создать относительный путь из двух сегментов. Аналогичным образом, код new Path("a\\b") позволяет создать путь с одним сегментом в платформах Unix и путь из двух сегментов в Windows.

Код модулей, создающих пути с помощью метода IPath.append(String), в котором предполагается специальное назначение символов ':' и '\' на всех платформах, может потребоваться обновить. В Eclipse 3.1 этот метод для интерпретации строки пути использует устройство операционной системы и разделители сегментов. Например, если выполнить append("a\\b") в платформе Unix, то будет добавлен один сегмент, а в Windows - два сегмента.

Все файлы данных, прочитанные и интерпретированные платформой больше не обрабатывают ':' и '\' как специальные символы на всех платформах. Все пути, хранящиется в файлах данных, которые могут читать несколько платформ, должны иметь переносимую форму. Например, в путях к файлам значков и другим файлам в plugin.xml в качестве разделителей сегментов пути должны использоваться только символы '/'.

3. Реестр расширений

Область действия: Модули, работающие с объектами IExtensionPoint, IExtension и IConfigurationElement из модуля платформы Eclipse или реестра расширений.

Описание: До версии 3.0 все объекты, предоставляемые реестром расширений (старое название - реестр модулей) можно было использовать во всех версиях. В Eclipse 3.0 была добавлена возможность динамического добавления и удаления модулей без перезапуска Eclipse. Если модуль удалялся без перезапуска, его записи в реестре расширений становились недопустимыми. В результате другой модуль, связанный с объектом, который изначально был предоставлен удаленной записью реестра расширений, мог содержать недопустимый объект. Соответствующее предупреждение можно получить только путем обработки событий IRegistryChangeEvent. Данная неполадка существовала, начиная с Eclipse 3.0. Однако на практике она встречается достаточно редко, поскольку модули, как правило, не удаляются без перезапуска Eclipse.

В версии 3.1 эта неполадка устранена следующим образом:

Требуемое действие: Если модуль предполагается использовать в динамическом режиме (с поддержкой динамически добавляемых и удаляемых модулей), то исходный код, связанный с объектами IExtensionPoint, IExtension и IConfigurationElement, предоставленными другими модулям, следует изменить на catch IRegistryChangeEvent, как в случае обрабатываемого исключения. Обработка исключений (в отличие от проверки isValid()) представляет собой единственный способ, гарантирующий правильное удаление модуля параллельной нитью.

4. Параметры программы форматирования исходного кода

Затронутые компоненты: модули, обращающиеся к параметрам программы форматирования исходного кода Java программным путем.

Описание: В Eclipse 3.0 для параметра программы форматирования исходного кода org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR допустимы только значения TAB и SPACE. В спецификации явным образом не указано, что тип значения представляет собой перечисление, которое может быть расширено в следующих выпусках. В Eclipse 3.1 для устранения ошибки 73104 добавлено третье значение - MIXED. В спецификация были внесены изменения, разрешающие добавление этого значения, а также дополнительных значений впоследствии.

Требуемое действие: Клиенты, использующие этот параметр программы форматирования исходного кода, должны учитывать новое значение. Указание непредвиденного значения опции приводит к возникновению ошибки.

5. Изменения контракта API для AntCorePreferences

Затронутые компоненты: модули, наследующие или создающие экземпляры org.eclipse.ant.core.AntCorePreferences

Описание: В Eclipse 3.0 наследование и создание экземпляров класса org.eclipse.ant.core.AntCorePreferences не запрещено. Эта случайная ошибка исправлена в Eclipse 3.1 путем явного запрета наследования и создания экземпляров этого класса.

Требуемое действие: Код клиентов, создающих экземпляры org.eclipse.ant.core.AntCorePreferences программным способом, следует обновить таким образом, чтобы параметры загружались с помощью org.eclipse.ant.core.AntCorePlugin.getPreferences(). Во всех подклассах потребуется отменить наследование org.eclipse.ant.core.AntCorePreferences.

6. Изменения контракта API для класса Policy в JFace

Затронутые компоненты: приложения RCP, переопределяющие протокол JFace, заданный рабочей средой.

Описание: В Eclipse 3.0 в протоколе рабочей среды сохраняются сообщения об ошибках JFace. Для этого протокол модуля рабочей среды передается непосредственно в org.eclipse.jface.util.Policy.setLog(ILog). В версии 3.1 из JFace удалена зависимость от ILog. Такой подход позволяет приложениям автономно использовать SWT и JFace за пределами среды выполнения Eclipse. Для обеспечения работы JFace добавлен новый интерфейс ILogger. Рабочая среда теперь использует ILogger вместо ILog. Дополнительная информация приведена в описании ошибки 88608.

Требуемое действие: Большинству приложений RCP не потребуется переопределять протокол, заданный рабочей средой. Однако если они вызывали Policy.setLog(ILog), то потребуется изменить их для передачи ILogger.

7. Изменения контракта API, разрешающие пустую проекцию по умолчанию

Затронутые компоненты: приложения RCP, ожидающие не пустую проекцию по умолчанию.

Описание: Для того чтобы разрешить запуск приложений RCP с пустого окна без проекций (расширение 71150), в методы WorkbenchAdvisor.getInitialWindowPerspectiveId() и IPerspectiveRegistry.getDefaultPerspective() были внесены изменения, позволяющие им возвращать нулевое значение. Поскольку в IDE всегда применяется проекция по умолчанию, IPerspectiveRegistry.getDefaultPerspective() не может вернуть нулевое значение. Аналогичным образом, если существующее приложение RCP получало от WorkbenchAdvisor.getInitialWindowPerspectiveId() значение, отличное от нуля, то IPerspectiveRegistry.getDefaultPerspective() также будет возвращать значение, отличное от нуля.

Требуемое действие: Дополнительные действия клиентов не требуются.

8. Изменения контракта API для IViewLayout

Затронутые компоненты: модули, реализующие org.eclipse.ui.IViewLayout.

Описание: В Eclipse 3.0 реализация класса org.eclipse.ui.IViewLayout не запрещена. Эта случайная ошибка исправлена в Eclipse 3.1 путем явного запрета реализации этого класса.

Требуемое действие: Во всех связанных классах потребуется отменить реализацию org.eclipse.ui.IViewLayout.

9. Изменения контракта API для IVMInstall

Затронутые компоненты: модули, реализующие org.eclipse.jdt.launching.IVMInstall.

Описание: В Eclipse 3.0 прямая реализация класса org.eclipse.jdt.launching.IVMInstall. запрещена. Эта случайная ошибка исправлена в Eclipse 3.1 путем явного запрета прямой реализации этого класса. Для того чтобы поддерживалась двоичная совместимость, клиентам разрешается реализовывать интерфейс напрямую, однако настоятельно рекомендуется использовать классы, производные от org.eclipse.jdt.launching.AbstractVMInstall. Кроме того, клиентам, реализующим IVMInstall, следует реализовывать новый необязательный интерфейс org.eclipse.jdt.launching.IVMInstall2, который теперь реализуется с помощью AbstractVMInstall. Во избежание неполадки, описанной в ошибке 73493, клиентам рекомендуется реализовывать новый интерфейс IVMInstall2. Рекомендуется миграция в подкласс AbstractVMInstall.

Требуемое действие: Все реализующие классы, которые не наследуют org.eclipse.jdt.launching.AbstractVMInstall, потребуется изменить для наследования org.eclipse.jdt.launching.AbstractVMInstall.

10.SelectionEnabler.SelectionClass доступен на уровне пакета

Затронутые компоненты: модули, использующие org.eclipse.ui.SelectionEnabler.SelectionClass.

Описание: В Eclipse 3.0 вложенный класс реализации org.eclipse.ui.SelectionEnabler.SelectionClass был общедоступным без каких-либо ограничений на его использование. Эта случайная ошибка исправлена в Eclipse 3.1 путем предоставления доступа к этому классу на уровне пакета.

Требуемое действие: Все классы, создающие экземпляры или расширяющие org.eclipse.ui.SelectionEnabler.SelectionClass, следует изменить, запретив обращение к этому классу.

11.ContributionItem.getParent() может возвращать нулевое значение

Затронутые компоненты: Модули, вызывающие getParent() в производном классе org.eclipse.jface.action.ContributionItem.

Описание: В Eclipse 3.0 не указано, что метод org.eclipse.jface.action.ContributionItem.getParent() может возвращать нулевое значение. Эта случайная ошибка исправлена в Eclipse 3.1; в документации по Java приведены соответствующие объяснения. Дополнительная информация приведена в описании ошибки 92777.

Требуемое действие: Код, вызывающий ContributionItem.getParent(), должен поддерживать обработку нулевого результата.

12.Изменения в isPropertySet(boolean) для IPropertySource и IPropertySource2

Затронутые компоненты: Модули, реализующие org.eclipse.ui.views.properties.IPropertySource и IPropertySource2.

Описание: В Eclipse 3.0 спецификация метода org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean) изменена неправильным образом; в ней указано, что значение true возвращается, если заданное свойство не имеет допустимого значения по умолчанию. В предыдущих версиях в этом случае возвращалось значение false. Это случайная ошибка при изменении API. Реализация работала без изменений, если вместо IPropertySource2 в исходном коде был реализован IPropertySource. В версии 3.1 данная ошибка исправлена путем возврата исходной спецификации IPropertySource.isPropertySet(boolean) (возврат false); IPropertySource2.isPropertySet(boolean) переопределяет эту спецификацию для возврата значения true. Дополнительная информация приведена в описании ошибки 21756.

Требуемое действие: Все классы, реализующие IPropertySource или IPropertySource2, свойства которых могут не иметь допустимых значений по умолчанию, следует проверить, чтобы они возвращали подходящее значение для isPropertySource(boolean). Клиенты должны проверить правильность работы кнопки Восстановить значение по умолчанию на панели Свойства.

13. элемент handlerSubmission удален из точки расширения org.eclipse.ui.commands

Затронутые компоненты: Модули, которые использовали экспериментальный элемент handlerSubmission, представленный в точке расширения Eclipse 3.0 org.eclipse.ui.commands.

Описание: В Eclipse 3.0 в точке расширения org.eclipse.ui.commands был представлен экспериментальный элемент. Он был предназначен для регистрации обработчиков через XML. После этого был введен механизм-предок, точка расширения org.eclipse.ui.handlers. Поскольку элемент был представлен как экспериментальный, теперь он удален.

Требуемое действие: Все модули, определяющие элемент handlerSubmission, необходимо перенести в точку расширения org.eclipse.ui.commands.

14. Статическое неокончательное поле API GLOBAL_IGNORES_CHANGED в TeamUI сделано окончательным

Затронутые компоненты: Модули, которые задавали поле GLOBAL_IGNORES_CHANGED в TeamUI.

Описание: В Eclipse 3.0 поле GLOBAL_IGNORES_CHANGED добавлялось в класс TeamUI. Это поле является константой, с помощью которой событие изменения свойства показывает, что в список глобального игнорирования, поддерживаемый модулем Team, были внесены изменения. Это поле должно было быть обозначено как окончательное в версии 3.0. Его сделали окончательным в версии 3.1.

Требуемое действие: Модули, которые ранее задавали описанное выше поле, больше не задают его.

15. ClassCastException использует FillLayout

Затронутые компоненты: Модули, неправильно использующие FillLayout.

Описание: В Eclipse 3.0 данные макетов не были связаны с FillLayout, и если приложение связывало эти данные с дочерним объектом под управлением FillLayout, то они игнорировались. В Eclipse 3.1 в FillLayout была добавлена поддержка кэша информации о размере для повышения производительности при переформатировании. Кэшированные данные хранятся в объекте FillData, связанном с каждым дочерним объектом под управлением FillLayout. Если данные макетов в приложении неправильно связаны с дочерним объектом, то при вызове computeSize для родителя будет выброшено ClassCastException.

Требуемое действие: Найти в FillLayout все дочерние объекты, связанные с данными макетов, и остановить эту связь.

16. Выброшено IllegalArgumentException во время создания виджета с освобожденным родителем

Затронутые компоненты: Модули, обрабатывающие исключения во время создания виджетов.

Описание: Если в Eclipse 3.0 виджет создавался с освобожденным родителем, то исключение не выбрасывалось, а код виджета выходил из строя позже, либо выбрасывалось SWTException с текстом "Виджет освобожден". Если в Eclipse 3.1 виджет создается с освобожденным родителем, то конструктор выбросит IllegalArgumentException с текстом "Недопустимый аргумент".

Требуемое действие: Коду, управляющему SWTException при создании виджета, придется также управлять и IllegalArgumentException.