Ciências da Computação (CIn/UFPE - 2006) • Mestre em Inteligência Artifical (CIn/UFPE - 2009) • ”Doutoranda” em Linguagens de Programação (CIn/UFPE - ????) • Professora de Programação (FASE/Nabuco – desde 2010 até maio/17) • Instrutora/Consultora Java (Liferay – desde 2015) • Resumindo: 15 anos desde o primeiro contato com Java • Mas nem tudo são flores
nove milhões de desenvolvedores adotam o Java. Completou 22 anos em maio Classificada como antiga e estável Robusta e confiável Projetada com alguns conceitos obsoletos e uma estrutura monolítica. Diecil o reuso e a manutenção do código Problemas em dispositivos de baixa capacidade de processamento. Sim, ok. Mas…
embarcados) para uma rica coleção de bibliotecas • Trouxe problemas • Tamanho: O JDK sempre foi disponibilizado como um grande e indivisível artefato de software. Ao longo dos anos só aumentou • Complexidade: O JDK é profundamente interconectado, ou seja, as bibliotecas são muito dependentes umas das outras, compondo assim uma estrutura monolítica.
inesperadas entre APIs e suas respectivas implementações • Consequência imediata: • Alto tempo de inicialização • Alto consumo de memória • Degradação do desempenho das aplica ções • Para se ter uma ideia, o ”Alô mundo” • Carrega e inicializa mais de 300 classes • Gasta, em média, 100ms em uma máquina desktop.
e o consumo de memória. • Conjunto de módulos separados e independentes. • Idenpficar interconexões entre bibliotecas • Eliminar dependências quando possível. Com esse objetivo, a Oracle optou por dividir o JDK • Apenas os módulos necessários para inicializar a aplicação serão carregados. • Uplização de módulos poderá ser empregada não apenas pelo JDK, mas também por bibliotecas e aplicações. Consequências do JDK modular
bugs Rampdown Start 2017/02/09 All Tests Run 2017/02/16 Zero Bug Bounce 2017/03/16 Priorização e correção dos bugs Rampdown Phase 2 2017/07/06 Final Release Candidate 2017/07/27 2017/09/21 General Availability JSRs que envolvem Modularidade 200: The Modular JDK (Jigsaw/JSR 376 and JEP 261) 201: Modular Source Code 220: Modular Run-Time Images 238: Multi-Release JAR Files 259: Stack-Walking API 261: Module System 275: Modular Java Application Packaging 282: jlink: The Java Linker
convertidas em pedidos de padronização no JSR ou incluídas em padrões existentes JEP - escopo menor e mais focado que as JSR. Oracle anunciou o primeiro grupo de JEPs para o Java 9 (Java Enhancement Proposal) em agosto de 2014.
ainda não era neste momento o projeto Jigsaw prometido para versões anteriores do Java – mas sim um trabalho de limpeza no JDK preparando as bases para a modularidade. • Essa JEP estabeleceu limites claros para cada módulo ao mesmo tempo que o próprio JDK está sendo construído.
Jigsaw • Mas não é só isso • Suporte a HTTP/2 • A versão 2.0 do HTTP foi disponibilizada já há algum tempo, baseada na implementação do protocolo SPDY do Google, o qual recebeu críticas muito positivas, pois possibilita a aceleração da navegação na web. • REPL (Read–Eval–Print Loop) • Permite a desenvolvedores testar códigos interativamente, sem a necessidade de se preocupar com estruturas de classes e compiladores • Novas técnicas de garbage collection • Garbage First (também conhecido como G1GC) promete suportar heaps imensos com o mínimo de interrupções
9 (nosso objetivo aqui hoje): Destinado a trazer programação modular Depois de anos de negociações e múltiplas JSRs e JEPs, o projeto está assumindo sua forma final
• Substituição do mecanismo de classpath padrão a fim de evitar conflitos; • No more ClassNotFoundException J Será? 2. Forte encapsulamento (Strong encapsulation): • Permissão para um componente de um módulo declarar quais dos seus tipos declarados como públicos são acessíveis a outros módulos.
componente java (Um nível de abstração maior, em cima de package) • Possui um nome e um código descritivo • Deve informar se faz uso de tipos (classes, interfaces ou pacotes) de outros módulos • Como? Cláusula requires. • Além disso, pode ser necessário informar ao compilador quais tipos desse módulo podem ser acessados por outros. • Como? Cláusula exports.
localiza os módulos necessários e, ao contrário do sistema de classpath, garante que o código de um módulo acesse apenas os tipos dos módulos dos quais ele depende. • Também evita forte dependência (API – IMPL) • Um módulo pode declarar que utiliza (uses) uma interface (tipo genérico) em vez de uma classe (tipo específico) de um determinado serviço cuja implementação é fornecida (provided) em tempo de execução por outro modulo.
que depende de java.sql, por ex. • Que por sua vez, depende de outros módulos, e assim recursivamente, até todas as dependências resolvidas. • Isso gera um grafo • Obs. O compilador consegue identificar dependência cíclica • Se m1 referencia m2 e m3, e ambos referenciam z, ele só vai ser carregado 1 vez.
o ServiceLoader (Localiza provedores de serviço em tempo de execução na pasta META-INF/services) • Para dar suporte ao legado • Um módulo (com o mesmo nome do pacote) é criado para PROVER o serviço • Quando algum módulo requerer java.sql.Driver, por ex, ao invés de procurar em META-INF/services, que vai ter uma centenas de serviços, já acha diretamente no módulo que oferece o serviço.
comando para a linguagem Java • Possibilita a execução de declarações e expressões Java de forma interativa, sem classes ou métodos. • Ótima opção para iniciantes • Viabiliza experimentar algoritmos, criar protótipos ou até mesmo tentar utilizar uma nova API • Já pode ser testada por qualquer pessoa que baixar as versões early access do Java 9 (faz parte do projeto Kulla)