Utilizando os Aprimoramentos do Carregador de Classes

Última atualização: 9 de dezembro de 2002

O Eclipse 2.1 inclui vários aprimoramentos de desempenho, incluindo alguns na área de classloading. Para ajudar nisso, marcações foram adicionadas ao arquivo de manifesto do plug-in e esse arquivo explica sua utilização.

Ativação

Os aprimoramentos de desempenho do classloader são ativados automaticamente por padrão. Se o usuário quiser substituir esse comportamento e desativá-lo, poderá transmitir o argumento de linha de comandos -noPackagePrefixes ao executável do Eclipse.

Formato

A declaração dos prefixos do pacote no arquivo de manifesto do plug-in é indicada por um elemento packages para cada biblioteca declarada no arquivo. O elemento packages possui um atributo prefixes que lista os prefixos do pacote dessa biblioteca.

É bastante comum que os arquivos jar contenham código que resida em vários pacotes. por exemplo, o plug-in org.eclipse.core.runtime contém código nos seguintes pacotes:
    org.eclipse.core.runtime
    org.eclipse.core.internal.runtime,
    org.eclipse.core.internal.plugins
    org.eclipse.core.runtime.model
.

Nesse caso, plugin.xml especifica:

    <runtime>
        <library name="runtime.jar">
            <export name="*"/>
            <packages prefixes="org.eclipse.core"/>
        </library>
    </runtime>

Observe que org.eclipse.core é um prefixo comum para todos os pacotes no plug-in. A alternativa é declarar todos os 4 prefixos no arquivo como uma lista separada por vírgulas. Nesse caso, deve-se pesar as desvantagens entre o número de verificações requeridas para várias entradas e um prefixo que pode incluir acessos falsos. Dependendo da maneira que o seu código está estruturado, pode ser melhor listar de 5 a 10 prefixos de pacotes em vez de utilizar um prefixo mais geral. Por exemplo, se todo o seu código espalhado por vários plug-ins contiver o mesmo prefixo (por exemplo com.mycompany) você não estará aproveitando completamente todos os benefícios se listar apenas o prefixo exclusivo "com.mycompany" no arquivo.

Quando um plug-in contém várias declarações de bibliotecas, cada uma deve ser responsável pelos prefixos do pacote de seu jar.

Se você escolher não incluir elementos packages no manifesto do seu plug-in, seu código ainda funcionará, mas não será possível aproveitar a otimização de carregamento de classes. Observe que sua lista de prefixos de pacotes deve estar completa para todos os pacotes em todas as bibliotecas do seu plug-in. Se essa lista não estiver completa, seu código não funcionará.

Utilizar com o arquivo de propriedades do carregador de classes

Nas compilações do Eclipse 2.0.2 e do antigo Eclipse 2.1 Integration, foi adicionado um recurso para permitir ao usuário especificar um arquivo de propriedades de carregador de classes que contém os prefixos de pacotes para ativar as melhorias do classloader. A utilização desse arquivo é especificada aqui.

O Eclipse 2.1 é totalmente compatível com versões anteriores do arquivo de propriedades do carregador de classes e, de fato, pode ser utilizado juntamente com as declarações de prefixos de pacotes no manifesto do plug-in. Esta seção descreve o comportamento da interação entre esses dois mecanismos.

Comportamento padrão: (nenhum argumento de linha de comandos) Os prefixos de pacotes serão lidos do arquivo plugin.xml e aplicados à estratégia de carregamento de classes. O arquivo classloader.properties não é acessado ou considerado.

Utilização de -classloaderProperties: Os prefixos dos pacotes são lidos do arquivo plugin.xml e, em seguida, o arquivo classloader.properties é lido. Se houver uma entrada no arquivo de propriedades do classloader para um plug-in que tinha prefixos definidos no arquivo de manifesto, a entrada no arquivo de propriedades irá substituir e terá precedência. (os resultados NÃO são mesclados.) Se a entrada no arquivo de propriedades não contiver um valor (por exemplo, org.eclipse.core.runtime=), quaisquer prefixos declarados no arquivo de manifesto serão removidos e a estratégia de carregamento de classes terá como padrão a não utilização das melhorias.

Utilização de -noPackagePrefixes: Quaisquer prefixos de pacotes declarados no arquivo de manifesto do plug-in serão ignorados e o arquivo de propriedades do carregador de classes também não será levado em consideração. A estratégia de carregamento de classes terá como padrão a não utilização das melhorias de prefixo.

Utilização de -classloaderProperties e -noPackagePrefixes: Quaisquer declarações de pacotes no arquivo de manifesto do plug-in serão ignoradas. O arquivo de propriedades do carregador de classes será lido e quaisquer declarações definidas nele serão levadas em consideração durante o carregamento de classes.

Resolução de Problemas

Se você obtiver um java.lang.ClassNotFoundException, essa será uma indicação de que pode haver um problema com suas entradas no manifesto ou nos arquivos de propriedades. Tente executar o Eclipse com o argumento de linha de comandos -noPackagePrefixes e NÃO utilize o argumento -classloaderProperties. Isso desativará todas as melhorias de carregamento de classes com respeito aos prefixos de pacotes.

Se o seu código for executado corretamente após fazer isso, os arquivos podem ter a sintaxe correta, mas os prefixos de pacotes na lista separada por vírgulas pode ter algumas entradas faltando. Para verificar se esse é o problema, comente as linhas apropriadas no arquivo. Utilize o sinal de sustenido (#) para comentar a linha do plug-in com problema no arquivo de propriedades ou utilize caracteres de comentários do HTML (<!-- ... -->) para comentar a declaração de pacotes no arquivo plugin.xml com problema.

Problemas Conhecidos

Se um arquivo de manifesto de plug-in declarar a lista de prefixos de pacotes, todos os fragmentos dos quais recebeu contribuição também devem listar seus prefixos de pacotes. Caso contrário, isso resultará em um problema NoClassDefFoundError. Isso pode ser resolvido pela utilização do argumento da linha de comandos -noPackagePrefixes para desativar as melhorias do classloader ou pela adição de entradas de prefixos de pacotes apropriadas ao plug-in e todos os seus fragmentos.

Copyright IBM Corporation e outros 2000, 2003.