Dê o próximo passo e inicie sua carreira
Dê o próximo passo e inicie sua carreira agora mesmo
4 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Em 2009, o engenheiro chefe da plataforma Java na Oracle, Mark Reinhold, falou no evento JavaOne a famosa frase “The classpath is dead.”. Desde a época muito se escreveu sobre o projeto JigSaw que visa modularizar a plataforma Java, mas a implementação final só sairá para o Java 9, caso o trem não se atrase novamente.
O objetivo principal do Jigsaw é trazer a modularização para a plataforma Java, mas há outras motivações: diminuir o tamanho de download (footprint) e melhorar o desempenho principalmente na inicialização (bootstrap).
Apesar do lançamento do projeto JigSaw ter sido procrastinado do Java 7 para o Java 9, foi criada uma solução intermediária para a versão 8 do Java. No Java 8 já foram definidos os perfis da plataforma, também chamados de Compact Profiles. São três profiles (1, 2 e 3) que são compostos de vários pacotes. 1 é o menor e possui apenas os pacotes mais importantes como e , se baseia no 1 e adiciona outros pacotes como . O último, , possui pacotes mais específicos como .
Ambientes de Código: conheça as vantagens e desvantagens
Ler mais
Django: QuerySets e ORM
Ler mais
Game Loop: como jogos atualizam e desenham a tela
Ler mais
java.langjava.utiljava.sqljavax.naming
O JavaDoc possui a lista completa dos pacotes e, na descrição de cada classe, foi adicionada uma declaração que documenta os perfis compatíveis.
Os Compact Profiles tornam o Java ainda mais interessante para sistemas embarcados, pois é possível gerar uma JRE especificando um desses 3 profiles. Para tal existe a ferramenta jrecreate que vem com o download do JavaSE Embedded. Por exemplo, ao gerar uma JRE no perfil Compact 1, um arquivo em torno de 11MB é gerado, possível usar em um RaspberryPI: jrecreate.sh --profile compact1 --dest /tmp/smallJRE/
Para a aplicação realmente funcionar em um determinado perfil, o compilador Java ganhou um novo flag: -profile. Esse flag determina o perfil (compact1, compact2 ou compact3) e o javac gera um erro caso uma classe incompatível esteja sendo utilizada.
Por exemplo, para compilar a classe abaixo é preciso usar pelo menos o Compact 2, pois o pacote java.sql não faz parte do Compact 1:
import java.sql.\*;
class Teste {
public static void main(String... args) throws SQLException { Connection c = DriverManager.getConnection("teste"); System.out.println("oi"); } }
javac -profile compact2 Teste.java //compact1 geraria um erro
Para saber se a classe faz parte de um profile ou não, foi criada uma outra ferramenta: jdeps (java dependency analyzer). Ela vem instalada com o JDK 8 e analisa os pacotes dependentes. Para a classe acima, a jdeps mostra a saída seguinte: `jdeps -verbose:class -P Teste.class
Teste.class -> /../jdk1.8.0_20.jdk/Contents/Home/jre/lib/rt.jar (compact2) Teste (Teste.class) -> java.io.PrintStream compact1 -> java.lang.Object compact1 -> java.lang.String compact1 -> java.lang.System compact1 -> java.sql.Connection compact2 -> java.sql.DriverManager compact2 -> java.sql.SQLException compact2`
Repare que a jdeps informa que a classe Teste depende do JAR rt.jar e relata todos os pacotes utilizados. jdeps também serve para analisar as dependências de um JAR. Veja abaixo um exemplo usando o JAR principal do Hibernate: `jdeps -P hibernate-core-4.3.6.Final.jar
hibernate-core-4.3.6.Final.jar → /../jdk1.8.0_20.jdk/Contents/Home/jre/lib/rt.jar (Full JRE) org.hibernate (hibernate-core-4.3.6.Final.jar) -> java.io compact1 -> java.lang compact1 -> java.math compact1 -> java.sql compact2 -> java.util compact1 -> javax.naming compact3 -> javax.transaction not found -> org.jboss.logging not found org.hibernate.action.internal (hibernate-core-4.3.6.Final.jar) -> java.io compact1 -> java.lang compact1 -> java.util compact1 -> java.util.concurrent.atomic compact1 … muito mais`
No Java 9, com a entrada do JigSaw, somos obrigados a definir mais meta informações sobre os JARs/Modulos como versionamento e imports/exports, que serão verificadas no build da aplicação. Isso também significa que várias bibliotecas e frameworks vão quebrar, pois se basearam em pacotes internos da JRE que o sistema de módulos vai proibir.
Para quem procura uma solução de modularização para já, deve dar uma olhada no OSGI que é foco da minha palestra na próxima QCon no Rio de Janeiro. Espero te encontrar lá!
Avalie este artigo