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.
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:
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.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.
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.
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:
IExtensionPoint
,
IExtension
e IConfigurationElement
especifican
ahora que InvalidRegistryObjectException
se enviará cuando el
objeto no sea válido. La excepción no está marcada, por lo que los clientes dinámicos que no lo sepan
no están obligados a marcarla.isValid()
, a estas interfaces
para que un cliente pueda determinar si un objeto sigue siendo válido.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).
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.
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
.
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.
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.
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
.
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.
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.
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.
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.
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
.
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.
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.
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.