Alterações necessárias ao adoptar mecanismos e APIs do 3.2

Esta secção descreve as alterações que são necessárias se estiver a tentar alterar o plug-in 3.1 para adoptar o mecanismo e as APIs do 3.2.

  1. Configurações de lançamento
  2. Modos de Lançamento
  3. Componentes Internacionais para Unicode para Java (ICU4J)
  4. Divisão de tempo de execução

Configurações de lançamento

Correlação de recursos da configuração de lançamento

O Eclipse 3.2 faculta uma nova infra-estrutura para associar as configurações de lançamento aos recursos. Esta correlação permite que a plataforma execute filtrações baseadas em recursos nas configurações de lançamento e que, opcionalmente, elimine essas configurações quando for eliminado um projecto a elas associado. A caixa de diálogo de lançamento foi aperfeiçoada de forma a suportar um conjunto de filtros para ocultar opcionalmente as configurações associadas a projectos fechados e eliminados. Do mesmo modo, a caixa de diálogo de lançamento suporta a filtração baseada nos conjuntos de trabalho seleccionados na janela activa da área de trabalho, que também pode ser seleccionada na caixa de diálogo de lançamento.

É da responsabilidade do cliente gerir a correlação das configurações de lançamento. A API foi adicionada a ILaunchConfigurationWorkingCopy, para definir os recursos associados à configuração, e a ILaunchConfiguration, para obter os recursos associados à configuração. Por exemplo, os separadores de lançamento, os atalhos de lançamento e os participantes de refactorização deverão ser considerados aquando da migração. O código que cria ou modifica as configurações de lançamento devem também actualizar as correlações dos recursos.

Suporte de migração da configuração de lançamento

O Eclipse 3.2 faculta uma nova infra-estrutura para migrar as configurações de lançamento, para que se sejam compatíveis com ferramentas novas. Por exemplo, no Eclipse 3.2, foi adicionado suporte para executar o filtro baseado em recursos nas configurações de lançamento. As configurações de lançamento necessitam de ser actualizadas, de modo a facultarem correlações de recursos para explorar esta nova função. Os utilizadores podem migrar manualmente as configurações de lançamento no espaço de trabalho a partir da página de preferências Executar/Depurar > Lançamento > Configurações de Lançamento, ao premir o botão Migrar.

Um novo atributo delegado de migração opcional foi adicionado ao ponto de extensão launchConfigurationTypes, especificando uma classe que implementa a nova interface ILaunchConfigurationMigrationDelegate. Um delegado de migração é responsável pela identificação e migração de candidatos de migração.

Modos de Lançamento

Um novo atributo opcional foi adicionado ao ponto de extensão launchModes para suportar adequadamente a exteriorização das etiquetas de acção dos submenus de lançamento. Os clientes que contribuem com modos de lançamento, devem especificar a etiqueta adequada para a utilização de submenus de lançamento, tais como "Executar Como". O novo atributo denomina-se launchAsLabel. As etiquetas adequadas são facultados pela plataforma para executar, depurar e perfilar os modos de lançamento. Para haver compatibilidade com outras edições, quando o novo atributo não é especificado para um modo de lançamento, as etiquetas do submenu são geradas do mesmo modo que anteriormente, através do MessageFormat com "{0} As". Consulte o erro relacionado 105235.

Componentes Internacionais para Unicode para Java (ICU4J)

O ICU4J é um conjunto de bibliotecas Java que faculta um suporte mais abrangente para Unicode e para a globalização e internacionalização de software. Para facultar esta funcionalidade à comunidade do Eclipse, o ICU4J foi adicionado à plataforma construída para o Eclipse 3.2. Poderá visualizá-lo na construção como sendo um plug-in denominado com.ibm.icu. A plataforma do Eclipse utilizará as API do ICU no Eclipse 3.2.

Migração

A migração do código de aplicação pode ser feito incrementalmente, o que significa que a completa adopção da função ICU4J não é necessária para recolher os benefícios da utilização do ICU4J. Consulte a página ICU4J no Eclipse wiki, para mais detalhes sobre como migrar o código para utilizar o ICU4J.

Plug-in de Substituição do ICU4J

A adição do plug-in do ICU4J adiciona na ordem do 3MB à nota de rodapé. Algumas aplicações poderão não desejar absorver o ICU4J, caso o tamanho da aplicação tenha precedência sobre a adopção da função ICU4J. Se for o caso, está disponível um plug-in de substituição (com.ibm.icu.base) a partir da página de construção da plataforma Eclipse. Descarregue o plug-in, remova o plug-in com.ibm.icu e os respectivos duplicados de origem a partir do /directório de plug-ins e largue-o no plug-in de substituição. Este procedimento é necessário uma vez que a plataforma Eclipse adoptou as API do UCI para a versão 3.2. Por conseguinte, a simples remoção do plug-in do ICU resultará na compilação de erros no código da plataforma. O plug-in de substituição tem um tamanho cerca de 100KB e simplesmente chama através da implementação do JDK predefinido das classes e APIs mais utilizadas no ICU4J. Mais uma vez, pode consultar a página ICU4J no Eclipse wiki, para mais detalhes sobre a utilização do plug-in de substituição de ICU.

Efeito no JFace - ViewerSorter e StructuredViewer

Para suportar o ICU4J no JFace, tornou-se necessária a existência de algumas adições de API criativas para evitar a referência às classes de ICU na API. Isto resultou na adição de:

  1. uma nova classe denominada org.eclipse.jface.viewers.ViewerComparator, da qual org.eclipse.jface.viewers.ViewerSorter é agora uma subclasse.
  2. dois novos métodos para org.eclipse.jface.viewers.StructuredViewer, para suportar a adição de org.eclipse.jface.viewers.ViewerComparator.

Motivo

A classe ViewerSorter contém um método público getCollator() que apresenta um java.text.Collator. Uma vez que este método é API, não poderia simplesmente ser alterado para utilizar o ICU Collator. As classes ICU também não podem fazer parte do API (assinaturas) do mesmo modo que uma dependência directa do plug-in no ICU iria evitar que o JFace fosse utilizado em modo autónomo (com SWT). Para acomodar estas restrições, foi adicionada a classe ViewerComparator que utiliza o java.util.Comparator, em vez de uma Intercaladora do ICU. Este procedimento foi realizado uma vez que a classe da Intercaladora do ICU implementa o java.util.Comparator, e, por conseguinte, qualquer StructuredViewer pode utilizar a Intercaladora do ICU em vez de java.text.Collator, mas o JFace não tem de adicionar uma dependência no plug-in do ICU4J. Os dois novos métodos adicionados ao suporte StructuredViewer ao utilizar a Intercaladora do ICU de modo a ordenar os conteúdos do visualizador através de uma ViewerComparator, em vez de um ViewerSorter. É recomendado que qualquer StructuredViewer utilize estes métodos de modo a obter/definir o ordenador do visualizador (comparador), em vez de utilizar os métodos getSorter() e setSorter(ViewerSorter).

Divisão de tempo de execução

Novas APIs de tempo de execução

O agrupamento org.eclipse.equinox.common inclui várias classes novas da API (por exemplo, Assert e ListenerList), que têm nomes comuns. Se o seu código contiver uma classe com o mesmo nome e utilizar instruções de importação * para importar a classe local e as classes do tempo de execução, poderá ser-lhe apresentada a seguinte mensagem de erro:

   O tipo ABC é ambíguo   

A organização das importações e a selecção da origem de importação adequada deverão resolver este problema.

Caminhos da classe explícitos nos scripts de construção personalizados

Como consequência da deslocação do código para novos plug-ins de tempo de execução, os scripts personalizados que referenciam explicitamente o org.eclispe.core.runtime poderão necessitar de adicionar um ou mais dos seguintes plug-ins: