Incompatibilidades Entre o Eclipse 3.0 e o 3.1

O Eclipse foi alterado de maneiras incompatíveis entre os releases 3.0 e 3.1 em maneiras que afetam plug-ins. As seguintes entradas descrevem as áreas que foram alteradas e fornecem instruções para migração de plug-ins 3.0 para 3.1. Observe que você precisa apenas consultar este documento se tiver problemas ao executar um plug-in 3.0 no 3.1.

  1. Preferências de Plug-in
  2. Alterações em Restrições do IPath
  3. Registro de Extensão
  4. Opções do Formatador de Código
  5. Alterações no Contrato da API para AntCorePreferences
  6. Alterações no Contrato da API para a Classe de Política no JFace
  7. Alterações no Contrato da API para Permitir uma Perspectiva Padrão Nula
  8. Alterações no Contrato da API para IViewLayout
  9. Alterações no Contrato da API para IVMInstall
  10. SelectionEnabler.SelectionClass Tornada Visível para o Pacote
  11. ContributionItem.getParent() Pode Retornar Nulo
  12. Alterações no isPropertySet(boolean) em IPropertySource e IPropertySource2
  13. Elemento handlerSubmission excluído do Ponto de Extensão org.eclipse.ui.commands
  14. Campo GLOBAL_IGNORES_CHANGED da API Sem Final Estático no TeamUI Determinado Final
  15. ClassCastException Utilizando FillLayout
  16. Criando um Widget com um Pai Descartado

1. Preferências do Plug-in

O que é afetado: Os plug-ins que inicializam os valores de preferência do plug-in padrão substituindo Plugin#initializeDefaultPreferences ou utilizam os listeners de alteração de preferência.

Descrição: No Eclipse 3.1, o objeto org.eclipse.jface.preference.IPreferenceStore obtido de org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore foi migrado para existir sobre a nova estrutura de preferências do Eclipse 3.0 fornecida pelo plug-in org.eclipse.core.runtime.

Ação requerida: Como resultado, clientes que utilizam APIs de preferências devem verificar dois problemas possíveis:

  1. O tipo dos objetos contidos nos eventos de alterações de preferências não é garantido. Os valores antigo e novo de eventos podem ser nulos, uma String ou um objeto digitado. Portanto, para ser um bom cliente, listeners de alterações de preferências devem poder manipular todas essas três possíveis situações.
  2. Se seus plug-ins utilizarem org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences você deverá incluir o plug-in org.eclipse.core.runtime.compatibility na sua lista de plug-ins requeridos, pois essa dependência foi removida do plug-in org.eclipse.ui.workbench.

Consulte a documentação Armazenamento de preferências para obter mais detalhes.

2. Alterações nas Restrições do IPath

O que é afetado: Plug-ins que criam, manipulam ou armazenam objetos IPath.

Descrição: No Eclipse 3.0, o IPath tinha várias restrições nos segmentos de caminhos que eram mais restritivas do que as restrições do sistema operacional básico. Elas incluíam:

Essas restrições foram removidas no Eclipse 3.1 quando o local (espaço de trabalho) dos dados da plataforma estão localizados em um sistema de arquivos que não tem restrições.

Ação requerida: Para ativar o tratamento apropriado do intervalo expandido de caminhos, todo o uso de Path e IPath dentro de plug-ins deve ser revisto e atualizado, conforme descrito a seguir. A maioria dos plug-ins não modificados continuará a se comportar exatamente como no 3.0 em todos os caminhos considerados legais no 3.0. No entanto, a não ser que essas alterações prescritas sejam feitas, elas provavelmente falharão em casos que envolvam caminhos considerados legais na 3.1 que eram ilegais na 3.0.

Plug-ins que armazenam representações de cadeia de caminhos em um formato que precisa ser legível entre diferentes plataformas devem migrar para o novo método de depósito de informações do provedor Path.fromPortableString. Esse método produz uma instância de IPath de um formato independente de plataforma. Essa representação de cadeia de caminhos pode ser criada utilizando o método IPath.toPortableString. Exemplos de arquivos de metadados que são afetados incluem arquivos que estão armazenados dentro de projetos do espaço de trabalho do Eclipse (.project, .classpath, etc) e todos os caminhos armazenados no armazenamento de preferências (org.eclipse.core.runtime.preferences.IPreferencesService).

Nota: fromPortableString lerá corretamente cadeias de caminho que foram criadas utilizando o método IPath.toString do Eclipse 3.0, mas não o método toString do Eclipse 3.1. Portanto, na maioria dos casos, nenhuma alteração é necessária em formatos de arquivo de metadados existentes, exceto para iniciar a gravar caminhos com toPortableString e a ler caminhos com fromPortableString.

Os plug-ins que estavam criando caminhos a partir de literais de cadeias com hardcode atribuído que assumiam que ':' e '\' tinham um significado especial em todas as plataformas precisarão ser migrados. A solução mais fácil é restringir literais de caminho de cadeia para o subconjunto que é suportado em todas as plataformas (evite caracteres de dois pontos e barra invertida). Literais de caminho podem suportar o conjunto completo de caminhos Unix válidos utilizando o formato de cadeia de caminho portável produzido por Path.toPortableString. Esse formato interpreta o primeiro dois pontos ':') único como o separador de dispositivos, a barra ('/') como o separador de segmentos e os dois-pontos duplos ("::") como um caractere de dois pontos literal. Por exemplo, o código new Path("c:/temp") agora criará um caminho relativo com dois segmentos em plataformas Unix. De forma semelhante, new Path("a\\b") agora criará um caminho com um segmento único em plataformas Unix e um caminho com dois segmentos no Windows.

Plug-ins que constroem caminhos utilizando o método IPath.append(String) que assumiam que ':' e '\' tinham um significado especial em todas as plataformas podem precisar atualizar seu código. No Eclipse 3.1, esse método utiliza delimitadores de dispositivos e de segmentos específicos do sistema operacional para interpretar a cadeia de caminho fornecida. Por exemplo, chamar append("a\\b") em plataformas Unix agora anexará um segmento único, enquanto que no Windows ele continuará a anexar dois segmentos.

Todos os arquivos de dados lidos e interpretados pela plataforma não mais tratarão ':' e '\' como caracteres especiais em todas as plataformas. Todos os caminhos armazenados nos arquivos de dados que podem ser lidos em várias plataformas, devem estar no formulário portável. Por exemplo, os caminhos de arquivos de ícone e outros caminhos em plugin.xml devem utilizar apenas '/' como o separador de segmento de caminho.

3. Registro de Extensão

O que é afetado: Plug-ins que manipulam ou retêm objetos IExtensionPoint, IExtension e IConfigurationElement do plug-in ou registro de extensão da Plataforma do Eclipse.

Descrição: Antes do 3.0, todos os objetos obtidos do registro de extensão (do registro do plug-in anterior) eram bons eternamente. Foram feitas alterações no Eclipse 3.0 que permitiram que plug-ins fossem incluídos ou removidos dinamicamente sem precisar reiniciar o Eclipse. Quando um plug-in é removido sem reinicialização, suas entradas no registro de extensão se tornam necessariamente inválidas. Isso indica que outro plug-in que mantenha um objeto obtido anteriormente da entrada do registro de extensão do plug-in excluído estará mantendo um objeto inválido. A única sugestão que um cliente poderia obter seria escutar o IRegistryChangeEvent. O problema existe desde o Eclipse 3.0, mas raramente é encontrado na prática, porque é altamente incomum que um plug-in seja removido sem reinicializar o Eclipse.

Esse problema foi resolvido no 3.1, da seguinte maneira:

Ação requerida: Se seu plug-in precisar ser dinamicamente consciente (isto é, capaz de lidar com adição ou remoção dinâmicas de plug-ins), o código que lida com objetos IExtensionPoint, IExtension e IConfigurationElement originados de algum outro plug-in deve ser alterado para capturar IRegistryChangeEvent exatamente como se ele fosse uma exceção verificada. Capturar a exceção (em vez de uma pré-verificação de isValid()) é a única maneira infalível de lidar com o caso de um plug-in que está sendo removido por um encadeamento simultâneo (o que, se ocorrer, com certeza será).

4. Opções do Formatador de Código

O que é afetado: Plug-ins que acessam opções do formatador de código Java de maneira programática.

Descrição: No Eclipse 3.0, os valores da opção do formatador de código org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR podiam ser apenas TAB ou SPACE. A especificação não fez nenhuma menção explícita de que o tipo de valor era uma enumeração que poderia crescer em releases futuros. No Eclipse 3.1, um terceiro valor possível, MIXED, foi incluído para resolver o erro 73104. A especificação foi alterada para incluir esse novo valor e permitir que mais valores sejam adicionados no futuro.

Ação requerida: Clientes que estão lendo ou configurando essa opção do formatador de código de maneira programática devem verificar seu código para considerar o novo terceiro valor e garantir que ele seja gravado de uma maneira robusta que falhe graciosamente se encontrar um valor de opção que não era antecipado.

5. Alterações no Contrato da API para AntCorePreferences

O que é afetado: Plug-ins que subclassificam ou instanciam org.eclipse.ant.core.AntCorePreferences

Descrição: No Eclipse 3.0, a classe org.eclipse.ant.core.AntCorePreferences não estava marcada como não podendo ser instanciada ou subclassificada por clientes. Essa era uma omissão que foi resolvida no Eclipse 3.1 com a classe marcada como não podendo ser subclassificada ou instanciada.

Ação requerida: Clientes que criam uma instância de org.eclipse.ant.core.AntCorePreferences de maneira programática devem migrar seu código para recuperar as preferências, utilizando: org.eclipse.ant.core.AntCorePlugin.getPreferences(). Qualquer subclasse precisará ser retrabalhada para não mais subclassificar org.eclipse.ant.core.AntCorePreferences.

6. Alterações no Contrato da API para Classe de Política no JFace

O que é afetado: Aplicativos RCP que substituem o log JFace configurado pelo workbench.

Descrição: No Eclipse 3.0, o workbench configurava o log do workbench como o log a ser utilizado para registrar erros do JFace, transmitindo o log do plug-in do workbench diretamente para o org.eclipse.jface.util.Policy.setLog(ILog). No 3.1, a dependência sobre o ILog foi removida do JFace para permitir que aplicativos independentes utilizem o SWT e o JFace fora do tempo de execução do Eclipse. Uma nova interface, ILogger, foi introduzida para atender às necessidades do JFace. O workbench foi alterado para fornecer um ILogger que agrupa o ILog do workbench. Para obter detalhes adicionais, consulte o erro 88608.

Ação requerida: A maioria dos aplicativos RCP não devem precisar substituir o log configurado pelo workbench, mas se anteriormente eles chamavam o Policy.setLog(ILog), precisarão ser alterados para, em vez disso, transmitir um ILogger.

7. Alterações no Contrato da API para Permitir uma Perspectiva de Padrão Nulo

O que é afetado: Aplicativos RCP que esperam uma perspectiva padrão não nula.

Descrição: Para permitir que aplicativos RCP iniciem com uma janela vazia sem nenhuma perspectiva aberta (aprimoramento 71150), WorkbenchAdvisor.getInitialWindowPerspectiveId() e IPerspectiveRegistry.getDefaultPerspective() foram alterados para permitir que um nulo seja retornado. No IDE, sempre existe uma perspectiva padrão, portanto IPerspectiveRegistry.getDefaultPerspective() não retornará um nulo. De forma semelhante, se um aplicativo RCP existente retornou um valor não nulo de WorkbenchAdvisor.getInitialWindowPerspectiveId(), IPerspectiveRegistry.getDefaultPerspective() retornará um valor não nulo.

Ação requerida: Nenhuma ação deve ser requerida por clientes.

8. Alterações no Contrato da API para IViewLayout

O que é afetado: Plug-ins que implementam o org.eclipse.ui.IViewLayout.

Descrição: No Eclipse 3.0, a classe org.eclipse.ui.IViewLayout.AntCorePreferences não estava marcada como não podendo ser implementada por clientes. Essa era uma omissão que foi resolvida no Eclipse 3.1 com a classe marcada como não podendo ser implementada por clientes.

Ação requerida: Todas as classes de implementação precisarão ser retrabalhadas para não mais implementar o org.eclipse.ui.IViewLayout.

9. Alterações no Contrato da API para IVMInstall

O que é afetado: Plug-ins que implementam o org.eclipse.jdt.launching.IVMInstall.

Descrição: No Eclipse 3.0, a classe org.eclipse.jdt.launching.IVMInstall não estava marcada como não podendo ser implementada diretamente por clientes. Essa era uma omissão que foi resolvida no Eclipse 3.1 com a classe marcada como não podendo ser implementada diretamente por clientes. Para manter a compatibilidade binária, ainda é permitido aos clientes implementar a interface diretamente, mas é fortemente recomendada a subclasse de clientes org.eclipse.jdt.launching.AbstractVMInstall. Os clientes que implementam IVMInstall também devem implementar a nova interface opcional org.eclipse.jdt.launching.IVMInstall2, que o AbstractVMInstall agora implementa. Recomenda-se que os clientes implementem a nova interface, IVMInstall2, para evitar o problema anotado no erro 73493. A migração recomendada é para a subclasse AbstractVMInstall.

Ação requerida: Todas as classes de implementação que ainda não subclassificam o org.eclipse.jdt.launching.AbstractVMInstall precisarão ser retrabalhadas para subclassificar o org.eclipse.jdt.launching.AbstractVMInstall.

10. SelectionEnabler.SelectionClass Tornado Visível para o Pacote

O que é afetado: Plug-ins que utilizam o org.eclipse.ui.SelectionEnabler.SelectionClass.

Descrição: No Eclipse 3.0, a classe de implementação aninhada org.eclipse.ui.SelectionEnabler.SelectionClass era pública, sem nenhuma restrição sobre seu uso. Essa era uma omissão que foi resolvida no Eclipse 3.1 com a classe tornando-se visível para o pacote.

Ação requerida: Todas as classes que instanciam ou estendem org.eclipse.ui.SelectionEnabler.SelectionClass precisarão ser retrabalhadas para não fazer mais referência a essa classe.

11. ContributionItem.getParent() Pode Retornar Nulo

O que é afetado: Plug-ins que chamam o getParent() em uma 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 retornar nulo. Essa era uma omissão que foi resolvida no Eclipse 3.1 com Javadoc para o método que clarifica quando ele pode retornar nulo. Para obter detalhes adicionais, consulte o erro 92777.

Ação requerida: Qualquer código que chame o ContributionItem.getParent() deve garantir que ele possa manipular um resultado nulo.

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

O que é afetado: Plug-ins que implementam org.eclipse.ui.views.properties.IPropertySource ou IPropertySource2.

Descrição: No Eclipse 3.0, a especificação para o método org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean) foi incorretamente alterada para especificar que verdadeiro deveria ser retornado se a propriedade especificada não tivesse um valor padrão significativo. Em versões anteriores, ele especificava que falso deveria ser retornado nesse caso. Essa era uma alteração da API de interrupção inadvertida, embora a implementação funcionasse da mesma forma que antes, se a origem da propriedade implementasse IPropertySource e não IPropertySource2. Isso foi corrigido no 3.1, com IPropertySource.isPropertySet(boolean) sendo revertido para sua especificação anterior (de que falso deveria ser retornado nesse caso) e IPropertySource2.isPropertySet(boolean) substituindo isso para especificar que verdadeiro fosse retornado nesse caso. Para obter detalhes adicionais, consulte o erro 21756.

Ação requerida: Todas as classes que implementam IPropertySource ou IPropertySource2, em que algumas das propriedades não têm valores padrão significativos, devem ser verificadas para garantir que retornem o valor apropriado para isPropertySource(boolean). Os clientes devem verificar se o botão Restaurar Valor Padrão na visualização Propriedades funciona conforme o esperado para sua origem de propriedade.

13. Elemento handlerSubmission Excluído do Ponto de Extensão org.eclipse.ui.commands

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

Descrição: No Eclipse 3.0, um elemento experimental foi apresentado no ponto de extensão org.eclipse.ui.commands. Esse elemento foi planejado como uma forma de registrar as rotinas de tratamento através do XML. Desde então, um mecanismo muito superior, o ponto de extensão org.eclipse.ui.handlers, foi apresentado. Visto que o elemento foi marcado como experimental, ele foi agora removido.

Ação requerida: Todos os plug-ins que definem um elemento handlerSubmission devem migrar para o ponto de extensão org.eclipse.ui.commands.

14. Campo GLOBAL_IGNORES_CHANGED da API Sem Final Estático no TeamUI Determinado Final

O que é afetado: Plug-ins que estavam configurando o campo GLOBAL_IGNORES_CHANGED de TeamUI.

Descrição: No Eclipse 3.0, o campo GLOBAL_IGNORES_CHANGED foi incluído na classe TeamUI. Esse campo é uma constante utilizada em um evento de alteração de propriedade, para indicar que a lista de itens ignorados globais mantida pelo plugin Team foi alterada. Ele não foi marcado final em 3.0, mas deveria ter sido. Ele foi determinado final em 3.1.

Ação requerida: Todos os plug-ins que estavam configurando o campo acima, não podem mais fazer isso.

15. ClassCastException Utilizando FillLayout

O que é afetado: Plug-ins que utilizam incorretamente o FillLayout.

Descrição: No Eclipse 3.0, nenhum dado de layout foi associado ao FillLayout e se um aplicativo designou dados de layout a um filho que foi gerenciado por um FillLayout, ele foi ignorado. No Eclipse 3.1, o suporte foi incluído no FillLayout para armazenar em cache informações de tamanho, para aprimorar o desempenho de redimensionamento. Os dados em cache são armazenados em um objeto FillData associado a cada filho gerenciado pelo FillLayout. Se um aplicativo designou incorretamente dados de layout para um filho, uma ClassCastException será lançada quando computeSize for chamado no pai.

Ação requerida: Localize qualquer filho em um FillLayout que tenha dados de layout designados e pare de designar os dados de layout.

16. IllegalArgumentException Lançada na Criação de um Widget com um Pai Descartado

O que é afetado: Plug-ins que capturaram exceções durante a criação de widgets.

Descrição: No Eclipse 3.0, se um widget foi criado com um pai descartado, nenhuma exceção foi lançada e o código do widget falhou em um ponto posterior ou uma SWTException com o texto "O Widget está Descartado" foi lançada. No Eclipse 3.1, se um widget for criado com um pai descartado, o construtor lançará um IllegalArgumentException com o texto "Argumento Inválido".

Ação requerida:Qualquer código que manipule a SWTException durante a criação de um widget, também precisará manipular a IllegalArgumentException.