Java Classloader - Java Classloader

O Java Class Loader é uma parte do Java Runtime Environment que carrega dinamicamente classes Java na Java Virtual Machine . Normalmente, as aulas são carregadas apenas sob demanda . O sistema de tempo de execução Java não precisa saber sobre arquivos e sistemas de arquivos, pois isso é delegado ao carregador de classes.

Uma biblioteca de software é uma coleção de códigos de objetos relacionados . Na linguagem Java , as bibliotecas são tipicamente empacotadas em arquivos JAR . As bibliotecas podem conter objetos de diferentes tipos. O tipo de objeto mais importante contido em um arquivo Jar é uma classe Java . Uma classe pode ser considerada uma unidade de código nomeada. O carregador de classes é responsável por localizar bibliotecas, ler seu conteúdo e carregar as classes contidas nas bibliotecas. Esse carregamento normalmente é feito "sob demanda", no sentido de que não ocorre até que a classe seja chamada pelo programa. Uma classe com um determinado nome só pode ser carregada uma vez por um determinado carregador de classes.

Cada classe Java deve ser carregada por um carregador de classes. Além disso, os programas Java podem fazer uso de bibliotecas externas (ou seja, bibliotecas escritas e fornecidas por alguém que não seja o autor do programa) ou podem ser compostas, pelo menos em parte, de uma série de bibliotecas.

Quando a JVM é iniciada, três carregadores de classes são usados:

  1. Carregador de classe de bootstrap
  2. Carregador de classes de extensões
  3. Carregador de classes do sistema

O carregador de classes de bootstrap carrega as bibliotecas Java principais localizadas no <JAVA_HOME>/jre/libdiretório. Este carregador de classes, que faz parte da JVM principal, é escrito em código nativo.

O carregador de classes de extensões carrega o código nos diretórios de extensões ( <JAVA_HOME>/jre/lib/extou qualquer outro diretório especificado pela java.ext.dirspropriedade do sistema).

O carregador de classes do sistema carrega o código localizado em java.class.path, que mapeia para a CLASSPATH variável de ambiente .

Carregadores de classes definidos pelo usuário

O carregador de classes Java é escrito em Java. Portanto, é possível criar seu próprio carregador de classes sem compreender os detalhes mais sutis da Java Virtual Machine. Cada carregador de classes Java possui um carregador de classes pai, definido quando um novo carregador de classes é instanciado ou configurado para o carregador de classes padrão do sistema da máquina virtual.

Isso torna possível (por exemplo):

  • para carregar ou descarregar classes em tempo de execução (por exemplo, para carregar bibliotecas dinamicamente em tempo de execução, mesmo de um recurso HTTP ). Este é um recurso importante para:
    • implementação de linguagens de script, como Jython
    • usando construtores de feijão
    • permitindo extensibilidade definida pelo usuário
    • permitindo que vários namespaces se comuniquem. Esta é uma das bases dos protocolos CORBA / RMI , por exemplo.
  • para alterar a forma como o bytecode é carregado (por exemplo, é possível usar bytecode de classe Java criptografado ).
  • para modificar o bytecode carregado (por exemplo, para entrelaçamento de aspectos no tempo de carregamento ao usar programação orientada a aspectos ).

Carregadores de classe em Jakarta EE

Os servidores de aplicativos Jakarta EE (anteriormente Java EE e J2EE) normalmente carregam classes de um WAR implementado ou arquivo EAR por uma árvore de carregadores de classes, isolando o aplicativo de outros aplicativos, mas compartilhando classes entre os módulos implementados. Os chamados " contêineres de servlet " são geralmente implementados em termos de vários carregadores de classes.

JAR inferno

JAR hell é um termo semelhante ao DLL hell usado para descrever todas as várias maneiras pelas quais o processo de carregamento de classe pode acabar não funcionando. Três maneiras pelas quais o inferno JAR pode ocorrer:

  • Presença acidental de duas versões diferentes de uma biblioteca instalada em um sistema. Isso não será considerado um erro pelo sistema. Em vez disso, o sistema carregará classes de uma ou outra biblioteca. Adicionar a nova biblioteca à lista de bibliotecas disponíveis em vez de substituí-la pode fazer com que o aplicativo ainda se comporte como se a biblioteca antiga estivesse em uso, o que pode ser verdade.
  • Múltiplas bibliotecas ou aplicativos requerem diferentes versões da biblioteca foo . Se as versões da biblioteca foo usam os mesmos nomes de classe, não há como carregar as versões da biblioteca foo com o mesmo carregador de classes.
  • Os problemas JAR mais complexos surgem em circunstâncias que tiram proveito de toda a complexidade do sistema de carregamento de classe. Um programa Java não precisa usar apenas um único carregador de classes "simples", mas, em vez disso, pode ser composto de vários (potencialmente muitos) carregadores de classes cooperantes e aninhados. As classes carregadas por diferentes carregadores de classes podem interagir de maneiras complexas não totalmente compreendidas por um desenvolvedor, levando a erros ou bugs que são difíceis de analisar, explicar e resolver.

A OSGi Alliance especificou (começando como JSR 8 em 1998) uma estrutura de modularidade que visa resolver o inferno JAR para VMs atuais e futuras em ME, SE e EE que é amplamente adotada. Usando metadados no manifesto JAR , os arquivos JAR (chamados de bundles) são conectados por pacote. Bundles podem exportar pacotes, importar pacotes e manter os pacotes privados, fornecendo as construções básicas de modularidade e gerenciamento de dependências com controle de versão.

Para remediar os problemas do inferno JAR, um Java Community Process  - JSR 277 foi iniciado em 2005. A resolução - Java Platform Module System  - pretendia introduzir um novo formato de distribuição, um esquema de versão de módulos e um repositório de módulos comum (semelhante em propósito a Microsoft .NET 's cache de Assembly global ). Em dezembro de 2008, a Sun anunciou que o JSR 277 foi colocado em espera. O Java Module System foi posteriormente reiniciado como "projeto Jigsaw", que foi incluído no Java 9 .

Veja também

Notas de rodapé

Referências

links externos