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.
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:
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.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.
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.
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:
IExtensionPoint
, IExtension
e
IConfigurationElement
agora especificam que InvalidRegistryObjectException
será emitido quando o objeto for inválido. A exceção é desmarcada para que clientes dinâmicos desprevenidos não sejam forçados a registrar entrada.isValid()
foi incluído nessas interfaces para que um cliente possa determinar se um objeto ainda é válido.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á).
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.
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
.
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
.
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.
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
.
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.
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.
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.
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.
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
.
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.
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.
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.