Incompatibilidades entre o Eclipse 3.0 e o 3.1

O Eclipse mudou relativamente à incompatibilidade entre o 3.0 e o 3.1 de formas que afectam os plug-ins. As entradas seguintes descrevem as áreas que foram alteradas e facultam instruções sobre a migração de plug-ins do 3.0 para 3.1. Repare que apenas necessita de ver aqui se está a detectar problemas com a execução do seu plug-in 3.0 em 3.1.

  1. Preferências do Plug-in
  2. Alterações às restrições de IPath
  3. Registo da extensão
  4. Opções do formatador de códigos
  5. Alterações do contrato da API para AntCorePreferences
  6. Alterações do contrato da API para a classe de Políticas em JFace
  7. Alterações do contrato da API para permitir uma perspectiva predefinida nula
  8. Alterações do contrato da API para IViewLayout
  9. Alterações do contrato da API para IVMInstall
  10. SelectionEnabler.SelectionClass tornada visível no pacote
  11. ContributionItem.getParent() pode devolver nulo
  12. Alterações a isPropertySet(boolean) em IPropertySource e IPropertySource2
  13. Elemento handlerSubmission eliminado do ponto de extensão org.eclipse.ui.commands
  14. Campo da API não final estático GLOBAL_IGNORES_CHANGED em TeamUI tornado final
  15. ClassCastException a utilizar FillLayout
  16. Criar um widget com um ascendente eliminado

1. Preferências do Plug-in

O que é afectado: Os plug-ins que inicializam os valores de preferências predefinidos do plug-in por sobreposição de Plugin#initializeDefaultPreferences ou utilizam receptores de alteração de preferência.

Descrição: No Eclipse 3.1, o objecto de org.eclipse.jface.preference.IPreferenceStore obtido de org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore foi migrado para ficar por cima da nova estrutura de preferência do Eclipse 3.0 facultada pelo plug-in org.eclipse.core.runtime.

Acção necessária: Como resultado, os clientes que utilizam as APIs de preferência devem verificar duas questões possíveis:

  1. O tipo de objectos contido nos eventos de alteração da preferência não é garantido. Tanto o valor antigo como o novo nos eventos pode ser nulo, um String ou um objecto tipificado. Deste modo, para serem bons clientes, os receptores de alteração da preferência devem poder processar as três situações possíveis.
  2. Se o plug-in utilizar org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences, terá de se certificar que inclui o plug-in org.eclipse.core.runtime.compatibility na lista de plug-ins requeridos, uma vez que esta dependência foi removida do plug-in org.eclipse.ui.workbench.

Consulte também o parágrafo Armazenamento de Preferências JFace na secção de alterações recomendadas deste manual.

2. Alterações às restrições de IPath

O que é afectado: Os plug-ins que criam, manipulam ou armazenam objectos IPath.

Descrição: No Eclipse 3.0, IPath tinha uma quantidade de restrições nos segmentos de caminhos que eram mais restritivas do que as restrições do sistema operativo subjacente. Estas incluem:

Estas restrições foram removidas no Eclipse 3.1 quando a localização (espaço de trabalho) dos dados da plataforma estiver num sistema de ficheiros que não tenha estas restrições.

Acção necessária: Para activar o tratamento adequado do âmbito expandido dos caminhos, toda a utilização de Path e IPath nos plug-ins deve ser revista e actualizada como está descrito em baixo. A maior parte dos plug-ins não modificados vai continuar a comportar-se exactamente como no 3.0 em todos os caminhos considerados legais no 3.0. Contudo, excepto se tiverem sido efectuadas estas alterações prescritas, é provável que falhem em casos que envolvam caminhos considerados legais no 3.1 que eram ilegais no 3.0.

Os plug-ins que armazenam as representações de cadeia dos caminhos num formato que tem de ser legível em plataformas diferentes devem migrar para o novo método factory Path.fromPortableString. Este método produz uma instância IPath de um formato independente da plataforma. Esta representação de cadeia dos caminhos pode ser criada utilizando o métodoIPath.toPortableString. Os exemplos de ficheiros de metadados que são afectados incluem ficheiros que são armazenados dentro de projectos do espaço de trabalho do Eclipse (.project, .classpath, etc) e todos os caminhos armazenados no armazém de preferências (org.eclipse.core.runtime.preferences.IPreferencesService).

Nota: fromPortableString vai ler correctamente todas as cadeias do caminho que foram criadas utilizando o método do Eclipse 3.0, IPath.toString, mas não o método do Eclipse 3.1, toString. Assim, na maioria dos casos não é necessária qualquer alteração aos formatos de ficheiros de metadados existentes, excepto para começar a escrever caminhos com toPortableString e a ler caminhos com fromPortableString.

Os plug-ins que estavam a criar caminhos de literais de cadeias em código estático que suponham que ":" e "\" tinham um significado especial terão de ser migrados. A solução mais fácil é restringir as literais do caminho de cadeia ao subconjunto que é suportado em todas as plataformas (evite caracteres de dois pontos e barra invertida). As literais de caminho podem suportar o conjunto completo de caminhos válidos de Unix, utilizando o formato de cadeia de caminho portátil, produzido por Path.toPortableString. Este formato interpreta os primeiros dois pontos (":") como o separador do dispositivo, a barra ("/") como um separador de segmentos e os dois pontos duplos ("::") como um carácter de dois pontos literal. Por exemplo, o código new Path("c:/temp") agora vai criar um caminho relativo com dois segmentos em plataformas Unix. De forma semelhante, new Path("a\\b") vai agora criar um caminho com um único segmento em plataformas Unix e um caminho com dois segmentos em Windows.

Os plug-ins que constroem caminhos utilizando o método IPath.append(String) que suponha que ":" e "\" tinham um significado especial em todas as plataformas, poderão ter de actualizar o respectivo código. No Eclipse 3.1, este método utiliza delimitadores de dispositivo e de segmento específicos do sistema operativo para interpretar a cadeia de caminho facultada. Por exemplo, ao chamar append("a\\b") em plataformas Unix vai agora anexar um único segmento, enquanto que em Windows vai continuar a anexar dois segmentos.

Quaisquer ficheiros de dados lidos e interpretados pela plataforma já não vão tratar ":" e "\" como caracteres especiais em todas as plataformas. Todos os caminhos armazenados em ficheiros de dados que podem ser lidos em várias plataformas têm de estar no formato portátil. Por exemplo, os caminhos de ficheiros de ícones e outros caminhos em plugin.xml só têm de utilizar "/" como o separador do segmento do caminho.

3. Registo da extensão

O que é afectado: Os plug-ins que manipulam ou retêm objectos IExtensionPoint, IExtension e IConfigurationElement do plug-in da Plataforma Eclipse ou do registo da extensão.

Descrição: Antes do 3.0, todos os objectos obtidos do registo da extensão (do anterior registo de plug-in) sempre estiveram em bom funcionamento. Foram efectuadas alterações no Eclipse 3.0 que permitiram que os plug-ins fossem adicionados ou removidos de forma dinâmica sem ter de reiniciar o Eclipse. Quando um plug-in é removido sem reiniciar, as suas entradas no registo de extensão, obrigatoriamente deixam de ser válidas. Isto significa que outro plug-in que dependa de um objecto obtido anteriormente da entrada de registo da extensão do plug-in eliminada ficaria com um objecto não válido. A única sugestão que um cliente obteria seria aguardar IRegistryChangeEvent. O problema existia desde o Eclipse 3.0, mas raramente é detectado na prática, porque é bastante invulgar que um plug-in seja removido sem reiniciar o Eclipse.

Este problema foi endereçado no 3.1 por:

Acção necessária: Se o plug-in tiver de ser consciente do dinamismo (ou seja, capaz de processar a adição na passagem ou remoção de plug-ins), o código que processar os objectos IExtensionPoint, IExtension e IConfigurationElement com origem noutro plug-in, tem de ser alterado para capturar IRegistryChangeEvent, exactamente como se fosse uma excepção verificada. A captura da excepção(em vez de uma verificação prévia isValid()) é a única forma infalível de processar o caso de um plug-in que está a ser movido por um módulo simultâneo (o que, a acontecer, será certamente).

4. Opções do formatador de códigos

O que é afectado: Os plug-ins que acedem de forma programática às opções do formatador de códigos Java.

Descrição: No Eclipse 3.0, os valores da opção do formatador de códigos org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR poderão apenas ser TAB ou SPACE. A especificação tornada não explícita menciona que o tipo de valor era uma enumeração que poderá aumentar em futuras edições. No Eclipse 3.1, um terceiro valor possível, MIXED, foi adicionado ao erro de endereço 73104. A especificação foi alterada para incluir este novo valor e para permitir que mais valores sejam adicionados de futuro.

Acção necessária: Os clientes que estiverem a ler ou a definir de forma programática esta opção do formatador de códigos devem verificar o código para levar em conta o novo terceiro valor e para assegurar que é escrito de forma robusta que falha graciosamente se algum a vez detectar um valor da opção que não tenha antecipado.

5. Alterações do contrato da API para AntCorePreferences

O que é afectado: Os plug-ins que colocam na subclasse ou instanciam org.eclipse.ant.core.AntCorePreferences

Descrição: No Eclipse 3.0, não estava marcada a classeorg.eclipse.ant.core.AntCorePreferences que os clientes não podem instanciar ou colocar na subclasse. Trata-se de uma negligência que tem sido abordada no Eclipse 3.1 com a classe marcada como não estando destinada a ser colocada na subclasse ou instanciada.

Acção necessária: Os clientes que criem de forma programática uma instância de org.eclipse.ant.core.AntCorePreferences devem migrar o seu código para obter as preferências, utilizando: org.eclipse.ant.core.AntCorePlugin.getPreferences(). Qualquer subclasse terá de ser retrabalhada para já não colocar org.eclipse.ant.core.AntCorePreferences na subclasse.

6. Alterações do contrato da API para a classe de Políticas em JFace

O que é afectado: As aplicações de RCP que sobrepõem o conjunto de registos JFace pela área de trabalho.

Descrição: No Eclipse 3.0, a área de trabalho define o registo da área de trabalho" como o registo a utilizar para registar erros de JFace, transmitindo o registo de plug-ins da área de trabalho para org.eclipse.jface.util.Policy.setLog(ILog). No 3.1, a dependência de ILog foi removida de JFace para activar aplicações autónomas utilizando SWT e JFace fora do tempo de execução do eclipse. Uma nova interface, ILogger, foi introduzida para ir de encontro às necessidades de JFace. A área de trabalho foi alterado para facultar um ILogger a translinear a área de trabalho ILog. Para obter mais detalhes, consulte o erro88608.

Acção necessária: A maioria das aplicações de RCP não devem necessitar de sobrepor o conjunto de registos com a área de trabalho, mas se já tiverem chamado anteriormente Policy.setLog(ILog), terão de ser alteradas para, em vez disso, transmitirem um ILogger.

7. Alterações do contrato da API para permitir uma perspectiva predefinida nula

O que é afectado: As aplicações de RCP que esperam uma perspectiva predefinida não nula.

Descrição: Para permitir que as aplicações de RCP comecem com uma janela vazia sem perspectivas abertas (aperfeiçoamento de 71150), WorkbenchAdvisor.getInitialWindowPerspectiveId() eIPerspectiveRegistry.getDefaultPerspective() foram alterados para permitir a devolução de nulo. No IDE, existe sempre uma perspectiva predefinida, por isso IPerspectiveRegistry.getDefaultPerspective() não irá devolver nulo. De forma semelhante, se uma ap de RCP existente devolveu anteriormente um valor não nulo de WorkbenchAdvisor.getInitialWindowPerspectiveId(), então IPerspectiveRegistry.getDefaultPerspective() ainda irá devolver um valor não válido.

Acção necessária: Não será exigida qualquer acção dos clientes.

8. Alterações do contrato da API para IViewLayout

O que é afectado: Os plug-ins que implementamorg.eclipse.ui.IViewLayout.

Descrição: No Eclipse 3.0, não estava marcada a classe org.eclipse.ui.IViewLayout que os clientes não podem implementar. Trata-se de uma negligência que foi abordada no Eclipse 3.1 com a classe que estava marcada como não tendo como objectivo ser implementada pelos clientes.

Acção necessária: As classes de implementação terão de ser retrabalhadas para deixar de implementar org.eclipse.ui.IViewLayout.

9. Alterações do contrato da API para IVMInstall

O que é afectado: Os plug-ins que implementamorg.eclipse.jdt.launching.IVMInstall.

Descrição: No Eclipse 3.0, a classe org.eclipse.jdt.launching.IVMInstall não estava marcada para que os clientes não a implementassem directamente. Trata-se de uma negligência que foi abordada no Eclipse 3.1 com a classe marcada como não tendo como objectivo ser implementada directamente pelos clientes. Para manter a compatibilidade binária, ainda permitimos aos clientes a implementação directa da interface, mas recomendamos vivamente que os clientes coloquem org.eclipse.jdt.launching.AbstractVMInstall na subclasse. Os clientes que implementam IVMInstall também devem implementar a nova interface opcional org.eclipse.jdt.launching.IVMInstall2, que AbstractVMInstall agora implementa. Recomenda-se que os clientes implementem a nova interface, IVMInstall2, para evitar o problema detectado no erro 73493. A migração recomendada é colocar AbstractVMInstall na subclasse.

Acção necessária: Quaisquer classes de implementação que ainda não tenham colocado org.eclipse.jdt.launching.AbstractVMInstall na subclasse vão ser retrabalhadas para colocar org.eclipse.jdt.launching.AbstractVMInstall na subclasse.

10. SelectionEnabler.SelectionClass tornada visível no pacote

O que é afectado: Os plug-ins que utilizam org.eclipse.ui.SelectionEnabler.SelectionClass.

Descrição: No Eclipse 3.0, a classe de implementação imbricada org.eclipse.ui.SelectionEnabler.SelectionClass era pública, sem restrições quanto à sua utilização. Trata-se de uma negligência que tem sido abordada no Eclipse 3.1 com a classe que estiver a ser visível em pacotes.

Acção necessária: Quaisquer classes a instanciar ou a expandirorg.eclipse.ui.SelectionEnabler.SelectionClass terão de ser retrabalhadas para deixarem de remeter para esta classe.

11. ContributionItem.getParent() pode devolver nulo

O que é afectado: Os plug-ins que chamemgetParent() numa subclasse de org.eclipse.jface.action.ContributionItem.

Descrição: No Eclipse 3.0, o método org.eclipse.jface.action.ContributionItem.getParent() não especificava que podia devolver nulo. Trata-se de uma negligência que tem sido abordada no Eclipse 3.1 com Javadoc para o método que clarifica quando poderá devolver nulo. Para obter mais detalhes, consulte o erro92777.

Acção necessária: Qualquer código a chamarContributionItem.getParent() tem de assegurar que pode processar um resultado nulo.

12. Alterações a isPropertySet(boolean) em IPropertySource e IPropertySource2

O que é afectado: Os plug-ins que implementam org.eclipse.ui.views.properties.IPropertySource ou IPropertySource2.

Descrição: No Eclipse 3.0, a especificação do métodoorg.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean) foi incorrectamente alterada para especificar que deve ser devolvido verdadeiro se a propriedade especificada não tinha um valor predefinido importante. Em versões anteriores, era especificado que devia ser devolvido false neste caso. Trata-se de uma alteração da API de interrupção inadvertida, apesar da implementação ter trabalhado o mesmo que antes se a origem da propriedade tivesse implementado IPropertySource e não IPropertySource2. Isto foi corrigido no 3.1, com IPropertySource.isPropertySet(boolean) a voltar a ser revertido para a especificação anterior (que devia ser devolvido false neste caso) e IPropertySource2.isPropertySet(boolean) a sobrepor para especificar que devia ser devolvido verdadeiro neste caso. Para obter mais detalhes, consulte o erro 21756.

Acção necessária: As classes que implementarem IPropertySource ou IPropertySource2, onde algumas propriedades não têm quaisquer valores predefinidos de importância, devem ser verificadas para assegurar que devolvem o valor apropriado para isPropertySource(boolean). Os clientes devem verificar se o botão Restaurar Valor Predefinido na vista Propriedades funciona como esperado para a origem da propriedade.

13. Elemento handlerSubmission eliminado do ponto de extensão org.eclipse.ui.commands

O que é afectado: Os plug-ins que utilizaram o elemento experimental handlerSubmission no ponto de extensão org.eclipse.ui.commands do Eclipse 3.0.

Descrição: No Eclipse 3.0, foi introduzido um elemento experimental no ponto de extensão org.eclipse.ui.commands. Este elemento era uma forma de registar rotinas de tratamento através de XML. Desde então, um mecanismo bastante superior, o ponto de extensãoorg.eclipse.ui.handlers, foi introduzido. Uma vez que o elemento foi marcado como experimental, agora foi eliminado.

Acção necessária: Os plug-ins que definem um elemento handlerSubmission devem migrar para o ponto de extensão org.eclipse.ui.commands.

14. Campo da API não final estático GLOBAL_IGNORES_CHANGED em TeamUI tornado final

O que é afectado: Os plug-ins que definiam o campo GLOBAL_IGNORES_CHANGED de TeamUI.

Descrição: No Eclipse 3.0, o campo GLOBAL_IGNORES_CHANGED foi adicionado à classe TeamUI. Este campo é uma constante utilizada num evento de alteração de propriedades para indicar que a lista de ignorar global mantida pelo plug-in Equipa foi alterada. Este campo não foi marcado como final no 3.0, mas devia ter sido. Foi tornado final no 3.1.

Acção necessária: Os plug-ins que definiam o campo acima já não o podem fazer.

15. ClassCastException a utilizar FillLayout

O que é afectado: Os plug-ins que utilizam incorrectamente FillLayout.

Descrição: No Eclipse 3.0, não estavam associados dados a FillLayout e se uma aplicação atribuiu dados de esquematização a um descendente que foi gerido por um FillLayout, a acção foi ignorada. No Eclipse 3.1, foi adicionado suporte a FillLayout para colocar na memória cache a informação do tamanho para melhorar o rendimento do redimensionamento. Os dados colocados na memória cache são armazenados num objecto FillData associados a cada descendente gerido por FillLayout. Se uma aplicação atribuiu incorrectamente dados de esquematização a um descendente, será lançada uma ClassCastException quando computeSize for chamado no ascendente.

Acção necessária: localizar os descendentes num FillLayout que tenham dados de esquematização atribuídos e parar de atribuir os dados da esquematização.

16. IllegalArgumentException lançada que cria um widget com um ascendente eliminado

O que é afectado: Os plug-ins que capturarem excepções ao criar widgets.

Descrição: No Eclipse 3.0, se um widget tiver sido criado com um ascendente eliminado, não foi lançada qualquer excepção e o código do widget falhou num ponto posterior ou foi lançada uma SWTException com o texto "Widget É Eliminado". No Eclipse 3.1, se for criado um widget com um ascendente eliminado, o construtor irá lançar uma IllegalArgumentException com o texto "Argumento não válido".

Acção necessária: Qualquer código que processe a SWTException ao criar um widget também terá de processar a IllegalArgumentException.