Incompatibilidades entre Eclipse 3.0 y 3.1

Entre las versiones 3.0 y 3.1, Eclipse ha cambiado de forma que presenta incompatibilidades que afectan a los conectores. Los siguientes puntos describen las áreas que han cambiado y suministran instrucciones para migrar conectores de la versión 3.0 a la versión 3.1. Tenga en cuenta que sólo necesita consultarlos si experimenta problemas al ejecutar el conector 3.0 en 3.1.

  1. Preferencias de conector
  2. Cambios en las restricciones de IPath
  3. Registro de extensiones
  4. Opciones del formateador de código
  5. El contrato API cambia a AntCorePreferences
  6. El contrato API cambia a clase Policy en JFace
  7. El contrato API cambia a permitir perspectiva por omisión nula
  8. El contrato API cambia a IViewLayout
  9. El contrato API cambia a IVMInstall
  10. SelectionEnabler.SelectionClass hecho visible como paquete
  11. ContributionItem.getParent() puede devolver un valor nulo
  12. Cambios en isPropertySet(boolean) en IPropertySource e IPropertySource2
  13. Elemento handlerSubmission suprimido del punto de extensión org.eclipse.ui.commands
  14. El campo API estático no final GLOBAL_IGNORES_CHANGED de TeamUI se ha convertido en final
  15. ClassCastException utiliza FillLayout
  16. Crear un widget con un agente desechado

1. Preferencias de conectores

Elementos afectados: conectores que inicializan sus valores de preferencias de conector por omisión alterando temporalmente Plugin#initializeDefaultPreferences o que utilizan escuchador de cambios de preferencias.

Descripción: en Eclipse 3.1, el objeto org.eclipse.jface.preference.IPreferenceStore obtenido de org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore se migró para existir sobre la nueva infraestructura de preferencias 3.0 de Eclipse proporcionada por el conector org.eclipse.core.runtime.

Acción necesaria: como resultado, los clientes que utilizan las API de preferencias deben comprobar dos posibles problemas:

  1. El tipo de los objetos contenidos en eventos de cambio de preferencias no está garantizado; tanto el valor antiguo como el nuevo en los eventos puede ser nulo, String o un objeto escrito. Por consiguiente, para ser un buen cliente, los escuchas de cambio de preferencias deben poder manejar estas tres situaciones posibles.
  2. Si el conector utiliza org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences, debe asegurarse de incluir el conector org.eclipse.core.runtime.compatibility en la lista de conectores necesarios del conector del usuario, ya que esta dependencia se ha eliminado del conector org.eclipse.ui.workbench.

Para obtener más detalles, consulte la documentación del almacén de preferencias.

2. Cambios en las restricciones de IPath

Elementos afectados: los conectores que crean, manejan o almacenan objetos IPath.

Descripción: en Eclipse 3.0, IPath tenía varias restricciones en los segmentos de vías de acceso que eran más restrictivas que las restricciones del sistema operativo subyacente. Eran las siguientes:

Estas restricciones se han eliminado en Eclipse 3.1 cuando la ubicación de los datos de la plataforma (área de trabajo) se encuentra en un sistema de archivos que no tiene estas restricciones.

Acción necesaria: para habilitar el tratamiento adecuado del rango ampliado de vías de acceso, debe revisarse y actualizarse todo el uso de Path e IPath en los conectores tal como se describe a continuación. La mayoría de los conectores no modificados seguirán comportándose exactamente como en la versión 3.0 en todas las vías de acceso consideradas válidas en la 3.0. Sin embargo, a menos que se realicen estos cambios indicados, es probable que se produzcan anomalías en los casos relacionados con vías de acceso que se consideran válidas en la versión 3.1 pero no lo eran en la 3.0.

Los conectores que almacenan representaciones de series de vías de acceso en un formato que tenga que ser legible en distintas plataformas deben migrar al nuevo método de fábrica Path.fromPortableString. Este método produce una instancia de IPath de un formato independiente de la plataforma. Esta representación de serie de vías de acceso puede crearse mediante el método IPath.toPortableString. Los ejemplos de archivos de metadatos afectados incluyen archivos que se almacenan en proyectos de área de trabajo de Eclipse (.project, .classpath, etc) y todas las vías de acceso almacenadas en el almacén de preferencias (org.eclipse.core.runtime.preferences.IPreferencesService).

Nota: fromPortableString leerá correctamente todas las series de vías de acceso que se crearon utilizando el método IPath.toString de Eclipse 3.0, pero no el método toString de Eclipse 3.1. Por consiguiente, en la mayoría de los casos no se necesita ningún cambio en los formatos de archivo de metadatos existentes, salvo para empezar a escribir vías de acceso con toPortableString y a leer vías de acceso con fromPortableString.

Conectores que creaban vías de acceso de literales de series codificadas que suponían que ':' y '\' tenían un significado especial en todas las plataformas que se tendrán que migrar. La solución más sencilla consiste en restringir literales de vía de acceso de serie al subconjunto soportado en todas las plataformas (evite los caracteres de dos puntos y barra inclinada invertida). Los literales de vía de acceso pueden dar soporte al conjunto completo de vías de acceso Unix válidas mediante el formato de serie de vía de acceso portable producido por Path.toPortableString. Este formato interpreta el primer carácter de dos puntos (':') como separador de dispositivos, la barra inclinada ('/') como separador de segmentos y doble signo de dos puntos ("::") como carácter de dos puntos literal. Por ejemplo, el código new Path("c:/temp") creará ahora una vía de acceso relativa con dos segmentos en las plataformas Unix. De manera similar, new Path("a\\b") creará ahora una vía de acceso con un solo segmento en las plataformas Unix y una vía de acceso con dos segmentos en Windows.

Es posible que los conectores que construyen vías de acceso utilizando el método IPath.append(String) que suponían que ':' y '\' tenían un significado especial tengan que actualizar su código. En Eclipse 3.1, este método utiliza delimitadores de segmento y dispositivo específicos del sistema operativo para interpretar la serie de vía de acceso proporcionada. Por ejemplo, llamar a append("a\\b") en las plataformas Unix agregará un solo segmento, mientras que en Windows se seguirán agregando dos segmentos.

Los archivos de datos leídos e interpretados por la plataforma ya no tratarán ':' y '\' como caracteres especiales en todas las plataformas. Todas las vías de acceso almacenadas en los archivos de datos que puedan leerse en varias plataformas deben estar en formato portable. Por ejemplo, las vías de acceso de los archivos de iconos y otras vías de acceso plugin.xml sólo deben utilizar '/' como separador de segmentos de vía de acceso.

3. Registro de extensiones

Elementos afectados: conectores que manejan o retienen objetos IExtensionPoint, IExtension e IConfigurationElement del registro de conectores o extensiones de la plataforma Eclipse.

Descripción: antes de la versión 3.0, todos los objetos obtenidos del registro de extensiones (del registro de conectores anterior) eran válidos para siempre. Se efectuaron cambios en Eclipse 3.0 que permitió que se añadiesen o eliminasen dinámicamente conectores sin tener que reiniciar Eclipse. Cuando se elimina un conector sin reiniciar, sus entradas en el registro de extensiones dejarán necesariamente de ser válidas. Esto quiere decir que otro conector que se mantiene en un objeto obtenido anteriormente de la entrada del registro de extensiones del conector suprimido se mantendría un objeto no válido. La única sugerencia de que podría obtenerse un cliente se debería a escuchar a IRegistryChangeEvent. El problema ha existido desde Eclipse 3.0, pero se encuentra raras veces en la práctica porque es muy inusual que se elimine un conector sin reiniciar Eclipse.

Este problema se ha corregido en la versión 3.1 mediante las acciones siguientes:

Acción necesaria: si el conector tiene que conocer la capacidad dinámica (es decir, ser capaz de gestionar la adición o eliminación de conectores sobre la marcha), el código que gestiona los objetos IExtensionPoint, IExtension e IConfigurationElement cuyo origen está en otro conector, debe modificarse para capturar IRegistryChangeEvent, exactamente como si fuera una excepción marcada. Capturar la excepción (en lugar de tener una comprobación previa isValid()) es la única manera totalmente segura de gestionar el caso de que una hebra concurrente elimine un conector (que casi con toda seguridad lo será si ocurre).

4. Opciones de formateador de código

Elementos afectados: los conectores que acceden programáticamente a las opciones de formateador de código Java.

Descripción: en Eclipse 3.0, los valores de la opción de formateador org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR sólo podían ser TAB o SPACE. La especificación no hacía ninguna mención explícita que el tipo de valor era una enumeración que podría aumentar en releases futuros. En Eclipse 3.1, un tercer valor posible, MIXED, se había añadido para resolver el error 73104. La especificación se ha modificado para incluir este nuevo valor y permitir que se añadan más valores en el futuro.

Acción necesaria: los clientes que leen o establecen programáticamente esta opción de formateador de códigos deben comprobar su código para tener en cuenta del tercer valor nuevo y asegurarse de que se ha escrito de manera sólida y que producirá una anomalía controlada si encuentra un valor de opción que no se había previsto.

5. El contrato API cambia a AntCorePreferences

Elementos afectados: los conectores que crean subclases o instancias de org.eclipse.ant.core.AntCorePreferences

Descripción: en Eclipse 3.0, la clase org.eclipse.ant.core.AntCorePreferences no se ha marcado para que los clientes no puedan crear instancias o subclases. Es un descuido que se ha resuelto en Eclipse 3.1 con la clase marcada como no prevista para que se creen subclases o instancias a partir de ella.

Acción necesaria: los clientes que creen programáticamente una instancia de org.eclipse.ant.core.AntCorePreferences deben migrar su código para recuperar las preferencias utilizando: org.eclipse.ant.core.AntCorePlugin.getPreferences(). Cualquier subclase tendrá que reelaborarse para no seguir creando subclases de org.eclipse.ant.core.AntCorePreferences.

6. El contrato API cambia a clase Policy en JFace

Elementos afectados: aplicaciones RCP que alteran temporalmente las anotaciones de JFace establecidas por el entorno de trabajo.

Descripción: en Eclipse 3.0, el entorno de trabajo establecía las anotaciones del entorno de trabajo como las que se utilizaban para anotar errores de JFace, pasando las anotaciones del conector del entorno de trabajo directamente a org.eclipse.jface.util.Policy.setLog(ILog). En la versión 3.1, la dependencia de ILog se ha eliminado de JFace para permitir que las aplicaciones autónomas utilicen SWT y JFace fuera del tiempo de ejecución de Eclipse. Una interfaz nueva, ILogger, se ha añadido para satisfacer las necesidades de JFace. El entorno de trabajo se ha modificado para proporcionar un ILogger que reinicie el ILog del entorno de trabajo. Para obtener más detalles, consulte el error 88608.

Acción necesaria: la mayoría de aplicaciones RCP no necesitan alterar temporalmente las anotaciones establecidas por el entorno de trabajo, pero si se llamaban anteriormente Policy.setLog(ILog), tendrán que modificarse para pasar un ILogger en su lugar.

7. El contrato API cambia para permitir una perspectiva por omisión nula

Elementos afectados: aplicaciones RCP que esperan una perspectiva por omisión no nula.

Descripción: para permitir que las aplicaciones RCP se inicien con una ventana vacía sin perspectivas abiertas (mejora 71150), WorkbenchAdvisor.getInitialWindowPerspectiveId() e IPerspectiveRegistry.getDefaultPerspective() se han modificado para que pueda devolverse un valor nulo. En IDE, existe siempre una perspectiva por omisión, por lo que IPerspectiveRegistry.getDefaultPerspective() no devolverá un valor nulo. De manera similar, si una aplicación RCP existente devolvió anteriormente un valor no nulo de WorkbenchAdvisor.getInitialWindowPerspectiveId(), IPerspectiveRegistry.getDefaultPerspective() seguirá devolviendo un valor no nulo.

Acción necesaria: no es necesario que los clientes realicen ninguna acción.

8. El contrato API cambia a IViewLayout

Elementos afectados: los conectores que implementan org.eclipse.ui.IViewLayout.

Descripción: en Eclipse 3.0, la clase org.eclipse.ui.IViewLayout no está marcada para que los clientes no la puedan implementar. Es un descuido que se ha resuelto en Eclipse 3.1 con la clase marcada como no prevista para que la implementen los clientes.

Acción necesaria: cualquier clase de implementación tendrá que reelaborarse para no seguir implementando org.eclipse.ant.ui.IViewLayout.

9. El contrato API cambia a IVMInstall

Elementos afectados: los conectores que implementan org.eclipse.jdt.launching.IVMInstall.

Descripción: en Eclipse 3.0, la clase org.eclipse.jdt.launching.IVMInstall no está marcada para que los clientes no la puedan implementar directamente. Es un descuido que se ha resuelto en Eclipse 3.1 con la clase marcada como no prevista para que la implementen los clientes directamente. Para mantener la compatibilidad binaria, todavía permitimos a los clientes que implementen la interfaz directamente, pero recomendamos encarecidamente que, en lugar de ello, los clientes creen la subclase org.eclipse.jdt.launching.AbstractVMInstall. Los clientes que implementen IVMInstall también deben implementar la nueva interfaz opcional org.eclipse.jdt.launching.IVMInstall2, que ahora implementa AbstractVMInstall. Se recomienda que los clientes implementen la nueva interfaz, IVMInstall2, para evitar el problema indicado en el error 73493. La migración recomendada consiste en crear la subclase AbstractVMInstall.

Acción necesaria: cualquier clase de implementación que no tenga ya la subclase org.eclipse.jdt.launching.AbstractVMInstall tendrá que reelaborarse como la subclase org.eclipse.jdt.launching.AbstractVMInstall.

10. SelectionEnabler.SelectionClass se ha hecho visible para paquetes

Elementos afectados: los conectores que utilizan org.eclipse.ui.SelectionEnabler.SelectionClass.

Descripción: en Eclipse 3.0, la clase de implementación anidada org.eclipse.ui.SelectionEnabler.SelectionClass era pública, sin restricciones en su utilización. Es un descuido que se ha resuelto en Eclipse 3.1 al hacer que la clase sea visible para paquetes.

Acción necesaria: cualquier clase que crea instancias o amplía org.eclipse.ui.SelectionEnabler.SelectionClass tendrá que reelaborarse para no seguir haciendo referencia a esta clase.

11. ContributionItem.getParent() puede devolver un valor nulo

Elementos afectados: los conectores que llaman a getParent() en una subclase de org.eclipse.jface.action.ContributionItem.

Descripción: en Eclipse 3.0, no se especificaba que el método org.eclipse.jface.action.ContributionItem.getParent() podía devolver un valor nulo. Es un descuido que se ha resuelto en Eclipse 3.1 con un Javadoc para el método que aclara cuándo puede devolver un valor nulo. Para obtener más detalles, consulte el error 92777.

Acción necesaria: cualquier código que llame a ContributionItem.getParent() debe asegurarse de que pueda manejar un resultado nulo.

12. Cambios a isPropertySet(boolean) en IPropertySource e IPropertySource2

Elementos afectados: los conectores que implementan org.eclipse.ui.views.properties.IPropertySource o IPropertySource2.

Descripción: en Eclipse 3.0, la especificación del método org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean) se ha modificado incorrectamente para especificarse que debe devolverse el valor true si la propiedad especificada no tenía ningún valor por omisión significativo. En versiones anteriores, se especificaba que en este caso se debía devolver el valor false. Había una ruptura inadvertida en el cambio de API, aunque la implementación funcionaba igual que antes si el origen de propiedad implementaba IPropertySource y no IPropertySource2. Esto se ha corregido en 3.1, con IPropertySource.isPropertySet(boolean) volverá a su especificación anterior (que en este caso debe devolverse el valor false) e IPropertySource2.isPropertySet(boolean) alterará temporalmente este valor para especificar que en este caso debe devolverse el valor true. Para obtener más detalles, consulte el error 21756.

Acción necesaria: cualquier clase que implemente IPropertySource o IPropertySource2, en que algunas propiedades no tienen valores por omisión significativos, deben marcarse para asegurar que devuelvan el valor adecuado para isPropertySource(boolean). Los clientes deben comprobar que el valor Restaurar valor por omisión en la vista Propiedades funciona como se esperaba para su origen de propiedad.

13. Elemento handlerSubmission suprimido del punto de extensión org.eclipse.ui.commands

Elementos afectados: conectores que utilizaron el elemento experimental handlerSubmission introducido en el punto de extensión org.eclipse.ui.commands de Eclipse 3.0.

Descripción: en Eclipse 3.0 se introdujo un elemento experimental en el punto de extensión org.eclipse.ui.commands. Este elemento se concibió como una manera de registrar manejadores mediante XML. Desde entonces se ha introducido un mecanismo muy superior, el punto de extensión org.eclipse.ui.handlers. Dado que el elemento se había marcado como experimental, ahora se ha eliminado.

Acción necesaria: cualquier conector que defina un elemento handlerSubmission debe migrarse al punto de extensión org.eclipse.ui.commands.

14. El campo API estático no final GLOBAL_IGNORES_CHANGED de TeamUI se ha convertido en final

Elementos afectados: conectores que establecieron el campo GLOBAL_IGNORES_CHANGED de TeamUI.

Descripción: en Eclipse 3.0, el campo GLOBAL_IGNORES_CHANGED se añadió a la clase TeamUI. Este campo es una constante que se utiliza en un evento de cambio de propiedades para indicar que la lista de omisiones globales mantenida por el conector Team ha cambiado. Este campo no se marcó como final e 3.0, pero debería haberse marcado. Se ha convertido en final en 3.1.

Acción necesaria: los conectores que se establecieron en el campo antedicho ya no lo están.

15. ClassCastException utiliza FillLayout

Elementos afectados: conectores que utilizan FillLayout incorrectamente.

Descripción: en Eclipse 3.0, no se han asociado datos de diseño a FillLayout y, si una aplicación asignó datos de diseño a un hijo gestionado por un FillLayout, se pasaron por alto. En Eclipse 3.1, se ha añadido soporte a FillLayout para guardar en antememoria la información de tamaño para mejorar el rendimiento del redimensionamiento. Los datos se almacenan en antememoria en un objeto FillData asociado a cada hijo gestionado por FillLayout. Si una aplicación ha asignado incorrectamente datos de diseño a un elemento hijo, se lanzará una ClassCastException cuando se llame a computeSize en el elemento padre.

Acción necesaria: busque hijos de un FillLayout que tengan datos de diseño asignados y deje de asignar los datos de diseño.

16. IllegalArgumentException lanzado al crear un widget con un agente desechado

Elementos afectados: conectores que capturan excepciones al crear widgets.

Descripción: en Eclipse 3.0, si se creó un widget con un padre desechado, no se lanzó ninguna excepción y el código de widget falló en un punto posterior o se lanzó una SWTException con el texto "El widget se ha desechado". En Eclipse 3.1, si se crea un widget con un padre desechado, el constructor lanzará una IllegalArgumentException con el texto "Argumento no válido".

Acción necesaria: el código que maneje la SWTException al crear un widget también tendrá que manejar la IllegalArgumentException.