Arquivo da tag: java 8

Java 8 e módulos: o estado atual do projeto Jigsaw

Mark Reinhold, arquiteto-chefe da plataforma Java na Oracle, publicou uma nota detalhando a situação atual do projeto Jigsaw e apontando novidades nessa área para o Java 8. O projeto Jigsaw tem como objetivo permitir a criação de módulos de sistemas (coleções de classes e interfaces) dentro da Plataforma Java.

Para obter a modularidade foram seguidos alguns princípios:

  • A linguagem Java em si precisa ter suporte à criação de módulos;
  • Os módulos devem controlar quais classes podem ser acessadas externamente a eles;
  • Deve haver uma identificação de versão, caso ocorra a necessidade de os módulos serem adicionados ou removidos durante a execução do programa.

A seguir, são mostrados exemplos de como será o uso de módulos.

O exemplo abaixo cria um módulo, informando a sua versão, e define qual o pacote de classes públicas será compartilhado com outros módulos:

module br.infoq.foo @ 1.0 {
/* Permite que os outros módulos tenham acesso às classes públicas deste pacote. */
exports br.infoq;
}

O exemplo a seguir cria um módulo que possui uma dependência com outro módulo (podendo ser especificada a versão):

module zoo {
requires br.infoq.foo @ 1.0;
}

Note que é informada uma dependência do módulo br.infoq.foo na versão 1.0. Pode-se também especificar uma condição, por exemplo @ >= 2.0, que nesse caso informa a necessidade de uma versão maior ou igual à versão 2.0 do módulo.

O exemplo a seguir cria um módulo que possui uma dependência e aproveita para compartilhar essa dependência com outros módulos. Também demonstra como definir quais módulos podem acessar o módulo em questão:

module bar {
/* Permite que os módulos dependentes de bar, também acessem o módulo zoo. */
requires public zoo;
/* Somente o módulo baz pode acessar este módulo. */
permits baz;
}

Mark Reinhold também descreveu tarefas pendentes, além de revisões que serão realizadas no projeto, e futuras implementações que ocorrerão na parte de compilação, empacotamento, bibliotecas, repositórios, API de modularização de sistemas e modularização do JDK. No site do Jigsaw há mais informações sobre o histórico do projeto, além de sua documentação.

Fonte: Rafael Sakurai/InfoQ

Java 8: Sintaxe de expressões Lambda será baseada em sintaxes de C# e Scala

Uma das funcionalidades mais aguardadas do Java 8 é a introdução de lambdas: funções anônimas que podem ser passadas como argumentos ou atribuídas a variáveis. Entretanto a sintaxe ainda estava em discussão, sendo inclusive feito uma enquete para determinar quais seriam as sintaxes mais populares.

Em uma mensagem recente de Brian Goetz na lista de discussões lambda-dev, foi anunciado que a sintaxe a ser adotada para os Lambdas na linguagem Java será baseada na sintaxe do C#. Pesou na decisão o fato desta sintaxe já ser bem conhecida e usada (o C# usa delegações desde a versão 1.0, tem suporte para funções de delegação na versão 2.0 e expressões lambda na versão 3.0).

Apesar de haver outras alternativas possíveis (tais como o BGGA) as respostas ao enquete levaram a crer que não havia vantagens significativas de nenhuma das sintaxes sobre as demais. Além disso, a experiência anterior dos que já utilizam C# e Scala indica que provavelmente já existem bem mais programadores familiares com este tipo de sintaxe. (A principal diferença entre os estilos de declaração de funções anônimas em C# e Scala é na forma como os tipos dos argumentos são indicados; C# usa “int foo” enquanto Scala usa “foo: int”, uma diferença com que se pode acostumar. Será adotado o estilo do C# devido à sua semelhança com a sintaxe para declaração de tipos de argumentos em Java.

Brian Goetz afirma que:

Apesar da procura extensiva, não houve um vencedor claro entre as alternativas (todas tem alguns aspectos desejáveis e outros não tão desejáveis, e não há nenhuma sintaxe que seja realmente melhor do que as outras). Assim, pensamos que seria melhor escolher algo que já foi comprovado na prática em duas linguagens que são bem semelhantes ao Java: C# e Scala, ao invés de algo totalmente novo.

Serão permitidos o uso de expressões e também de blocos. Uma expressão é representada sem o uso de chaves e devolve um resultado quando avaliada. Blocos serão declarados entre chaves e não devolverão nenhum valor a não ser que a palavra-chave return seja usada. Os seguintes exemplos foram apresentados na lista de discussão:

x => x + 1

(x) => x + 1

(int x) => x + 1

(int x, int y) => x + y

(x, y) => x + y

(x, y) => { System.out.printf("%d + %d = %d%n", x, y, x+y); }

() => { System.out.println("I am a Runnable"); }

Uma grande vantagem das expressões lambda é a capacidade de inferir tipos de argumentos, caso estes não estejam especificados explicitamente. Em alguns casos, o compilador pode não ser capaz de inferir os tipos corretos. Isso acontece especialmente no caso de operadores sobrecarregados; por exemplo, “(x,y) => x+y” não irá compilar se o Java não tiver informação de que x e y são long ou double (ou até mesmo Object). Na maioria dos casos, o mecanismo de inferência de tipos será capaz de gerar o código correto, mas caso seja necessário um auxílio adicional, o desenvolvedor sempre poderá incluir explicitamente os tipos dos argumentos.

Em breve estará disponível um compilador que reconhece a nova sintaxe, para testes e experimentações.

Fonte: Postado por Alex Blewitt/Traduzido por Wellington Pinheiro/InfoQ

Trabalhando com closures no Java 8

Criar em Java um simples Runnable ou ActionListener pode ocupar muitas linhas de código. A solução preferida dos programadores hoje é usar as classes anônimas do Java:

Runnable r = new Runnable() {

public void run() {

System.out.println(“Caelum”);

}

};

new Thread(r).start();

Depois de muitas propostas para closures no Java, a proposta atual de Lambdas para o Java 8 permite omitir a declaração do método, no caso de haver apenas um método abstrato naquela classe abstrata/interface (single abstract method):

Runnable r = #{System.out.println(“Caelum”)};

new Thread(r).start();

Mais ainda: o compilador consegue inferir um passo adiante, descobrindo que há um construtor em Thread que recebe como argumento uma interface que possui apenas um método abstrato. Repare que agora não precisamos escrever nem Runnable, nem run:

new Thread(#{System.out.println(“Caelum”)}).start();

Esses recursos, somados aos polêmicos defender methods (que permitem indicar “defaults” para métodos em interfaces), permitirão escrever lista.sortBy(#Usuario.getNome), muito mais sucinto do que invocar Collections.sort(lista, …) passando um  new Comparator() {…} que invoca

u1.getNome.compareTo().

Como rodar esses testes? O Java 7 está previsto já para junho, mas infelizmente não contemplará muitos dos esperados avanços na linguagem. Esses ficarão para meados de 2012, com o Java 8, mas você já pode experimentá-los. Para isso, precisa ter o Java 7 instalado (mac aqui). Depois precisa clonar o repositório do langtools:

hg clone http://hg.openjdk.java.net/lambda/lambda/langtools

Para compilar esse projeto, de dentro de langtools/make, executamos o ant passando referência para os diretórios de instalação do seu Java 6 e Java 7:

ant -Dboot.java.home=/usr/lib/jvm/java-6-sun -Dtarget.java.home=/algumdiretorio/jdk1.7.0 build-all-tools

Para compilar nosso código que utilize esses recursos do Java 8, precisamos do classes.jar gerado em dist/bootstrap/lib, que contem as classes necessárias para o compilador e também para a execução:

jdk1.7.0/bin/java -cp classes.jar com.sun.tools.javac.Main Classe.java

E para executar:

jdk1.7.0/bin/java -cp classes.jar:. Classe

Fonte: Paulo Silveira/Caelum

Ainda faltam ferramentas no Java 7

O Java 7, a primeira versão da plataforma de desenvolvimento aberto criada sob gestão da Oracle, foi lançada na última semana e pareceu não agradar usuários, que reclamaram da falta de alguns componentes prometidos inicialmente e de algumas falhas que poderiam estourar o compilador NullPointerException.

Para verificar o que há de errado com a nova versão do Java, o IT Web entrou em contato com o especialista em desenvolvimento para a plataforma Paulo Silveira, da Caelum. Segundo ele, inicialmente o Java 7 teria uma série de novidades, desde modularidade, com sistema de gestão integrada (SGI), até Off Closure, Defender Method e novidades para a inicialização de colections de forma mais sucinta.

Porém, ele afirmou que o atraso de mais de dois anos no lançamento da ferramenta fez com que a Oracle optasse por uma versão menos parruda do Java. “Alguém de dentro da Oracle disse que se a empresa fosse colocar todo o prometido dentro do pacote, o lançamento só iria ocorrer no final de 2012. Então o pessoal não quis esperar, porque já demorava quatro anos e iria levar mais outros dois”, pontuou. Silveira, explicou que, por isso, decidiram pela separação da plataforma de desenvolvimento aberto em duas versões: a que foi lançada na última semana e a Java 8, programada para o para inicio de outubro de 2012 com tudo o que falta.

Apesar das mudanças, ele garante que os desenvolvedores não vão sentir dificuldades de adaptação na nova plataforma. “De maneira alguma. Como todas as outras versões do Java ela é compatível com as anteriores. Então, tudo o que funcionava antes, funciona agora. Você pode continuar programando no Java 7 assim como fazia no Java 6.”

Quanto à falha com o compilador:

NullPointerException, Silveira revelou que a Oracle já tinha sido avisada pelos desenvolvedores de Apache Lucine de que não era compatível com o software, o que é um bug grande. Porém a empresa preferiu lançar a versão. O especialista explica como contornar esse bug. “Se você utilizar algumas opções por linha de comando para desabilitar algumas dessas otimizações mais agressivas, ele funciona perfeitamente, como da maneira antiga.” Segundo ele, a correção dessa falha já está prevista para a atualização do Java 7.

A reportagem procurou a Oracle para comentar o tema, mas até o fechamento da matéria, não obteve resposta.

Fonte: ItWeb