Obtendo recursos embutidos em JARs com NIO.2

Digamos que no nosso projeto temos a seguinte estrutura:

.
└── src
    ├── meu-pacote
    │   └── nio2
    │       └── MinhaClasse.java
    └── config.xml

Dentro de MinhaClasse, estou interessado em obter o conteúdo do arquivo config.xml.

Para isso:

  • obtemos a URI do recurso através do método getResource de nosso classe seguido ao método toURI
  • utilizamos o método get da classe auxiliar Paths para obter um Path a partir da URI
  • criamos uma String a partir dos bytes retornados pelo método readAllBytes da classe auxiliar Files
public class MinhaClasse {
  public static void main(String[] args) throws URISyntaxException, IOException {

    URI uriDoRecurso = MinhaClasse.class.getResource("/config.xml").toURI();
    Path pathDoRecurso = Paths.get(uriDoRecurso);
    String conteudoDoRecurso = new String(Files.readAllBytes(pathDoRecurso));
    System.out.println(conteudoDoRecurso);

  }
}

Ao executarmos o código anterior de dentro de nossa IDE, o código tem o efeito esperado. Tudo funciona!

Mas e se exportarmos para um JAR?

Digamos que nosso JAR seja chamado minha-lib.jar. Para que a nossa classe seja executada por padrão na execução do JAR, conteria a configuração Main-Class do arquivo META-INF/MANIFEST.MF.

O conteúdo de minha-lib.jar seria o seguinte:

.
├── meu-pacote
│   └── nio2
│       └── MinhaClasse.class
├── config.xml
├── META-INF
│   └── MANIFEST.MF

Poderíamos então executar o JAR com o comando:

java -jar minha-lib.jar

Teríamos como resultado a seguinte exceção:

Exception in thread "main" java.nio.file.FileSystemNotFoundException
	at com.sun.nio.zipfs.ZipFileSystemProvider.getFileSystem(ZipFileSystemProvider.java:171)
	at com.sun.nio.zipfs.ZipFileSystemProvider.getPath(ZipFileSystemProvider.java:157)
	at java.nio.file.Paths.get(Paths.java:143)
	at meu-pacote.nio2.MinhaClasse.main(MinhaClasse.java:14)

Porque será que foi lançada a exceção FileSystemNotFoundException?

O que acontece é que um recurso que está embutido dentro de um JAR tem uma URI diferente. No nosso caso, seria parecida com: jar:file:/home/alexandre/minha-lib.jar!/config.xml

Observe que temos primeiramente o caminho até o JAR e, depois do !, o caminho do recurso que está embutido dentro do JAR.

Nossa primeira alteração no programa deve ser a detecção que temos um recurso de um JAR. Podemos fazer isso verificando se há o caracter !:

URI uriDoRecurso = MinhaClasse.class.getResource("/config.xml").toURI();
Path pathDoRecurso;
if(uriDoRecurso.toString().contains("!")) { //é de JAR
  //lógica para obter recurso do JAR...
} else {
  pathDoRecurso = Paths.get(uriDoRecurso);
}

Para obter a URI do recurso relativa à URI do JAR, devemos utilizar a ideia de sistema de arquivos do NIO.2, disponível a partir do Java 7. Um sistema de arquivos é abstraído através da classe abstrata java.nio.file.FileSystem. Por padrão, é utilizado o sistema de arquivos do sistema operacional. Porém, podemos utilizar um sistema de arquivos a partir de um JAR ou arquivo ZIP.

Os seguintes passos deverão ser tomados:

  • separar as partes da URI que são do JAR e do recurso dentro do JAR
  • criar uma URI que aponta para o JAR
  • criar um FileSystem a partir da URI do JAR
  • obter o Path do recurso relativo ao sistema de arquivos do JAR

Teremos, então, o código:

URI uriDoRecurso = MinhaClasse.class.getResource("/config.xml").toURI();
Path pathDoRecurso;
if(uriDoRecurso.toString().contains("!")) { //é de JAR
  String[] partesDaURI = uriDoRecurso.toString().split("!");
  URI uriDoJAR = URI.create(partesDaURI[0]);
  FileSystem fs = FileSystems.newFileSystem(uriDoJAR, new HashMap<String, String>());
  pathDoRecurso = fs.getPath(partesDaURI[1]);
} else {
  pathDoRecurso = Paths.get(uriDoRecurso);
}

Copiando arquivos de um diretório e seus sub-diretórios com Java 7+

Vamos dizer que temos um diretório chamado arquivos com o seguinte conteúdo:

.
└── arquivos
    ├── .bookignore
    ├── book.properties
    ├── imgs
        └── cover.jpg
    └── .gitignore

Queremos copiar todos os arquivos bem como o conteúdo do sub-diretório imgs para outro diretório chamado copia.

Fazer isso é fácil com os novos recursos do pacote java.nio disponíveis a partir do Java 7. Essas novidades foram definidas na JSR-203 e ficaram conhecidas como NIO.2.

Até o Java 1.3, havia somente o pacote java.io sem suporte adequado a abstrações de alto nível como channel, apenas com I/O bloqueante, suporte ruim a character encodings.

O Java 1.4 veio com o pacote java.nio que resolvia várias dessas limitações.

Com o NIO.2 do Java 7, foi simplificada a API do pacote java.nio, dado suporte a I/O assíncrono, criada uma abstração de sistema de arquivos, entre outras melhorias.

Para representar um diretório, devemos usar a classe Path, obtendo instâncias a partir da classe auxiliar Paths.

Path origem = Paths.get("./arquivos");
Path destino = Paths.get("./copia");

Para navegar no diretório de origem de forma a incluir sub-diretórios (ou seja, recursivamente) podemos usar o método estático walkFileTree da classe auxiliar Files. Precisamos passar um objeto que implementa a interface FileVisitor.

Files.walkFileTree(origem, new Copiador(origem, destino));

A classe Copiador define todos os métodos exigidos pela interface FileVisitor:

  • preVisitDirectory – chamado antes de visitar um novo sub-diretório
  • postVisitDirectory – chamado depois de visitar um sub-diretório e todos seus descendentes
  • visitFile – chamado ao visitar cada novo arquivo
  • visitFileFailed – chamando quando há falha em algum arquivo

Em cada método, devemos retornar um valor da enum FileVisitResult. Retornaremos FileVisitResult.CONTINUE, para continuar a navegação recursiva nos sub-diretórios.

class Copiador implements FileVisitor<Path> {
  private Path origem;
  private Path destino;
  public Copiador(Path origem, Path destino) {
    this.origem = origem;
    this.destino = destino;
  }
  @Override
  public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) throws IOException {
    return FileVisitResult.CONTINUE;
  }
  @Override
  public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
    //copia arquivo para destino...
    return FileVisitResult.CONTINUE;
  }
  @Override
  public FileVisitResult visitFileFailed(Path file, IOException exc) throws IOException {
    throw exc;
  }
  @Override
  public FileVisitResult postVisitDirectory(Path dir, IOException exc) throws IOException {
    return FileVisitResult.CONTINUE;
  }
}

Ainda não preenchemos a lógica de copiar os arquivos, que deveria ficar no método visitFile.

Antes disso, podemos simplificar um pouco o código herdando da classe auxiliar SimpleFileVisitor e sobre-escrevendo apenas o método necessário.

class Copiador extends SimpleFileVisitor<Path> {
  private Path origem;
  private Path destino;
  public Copiador(Path origem, Path destino) {
    this.origem = origem;
    this.destino = destino;
  }
  @Override
  public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
    //copia arquivo para destino...
    return FileVisitResult.CONTINUE;
  }
}

No método visitFile, vamos pegar o caminho absoluto do arquivo que está sendo visitado transformando-o em um caminho relativo em relação ao diretório de origem.

Então, podemos obter o caminho do mesmo arquivo mas relativo ao destino.

Precisamos criar qualquer diretório “pai” intermediário necessário para o arquivo de destino, através do método estático createDirectories da classe auxiliar Files.

Aí, basta invocar o método estático copy de Files para efetuar a cópia.

No caso de algum diretório ou arquivo já existir, é lançada a exceção FileAlreadyExistsException, que vamos ignorar.

Teremos o código:

Path caminhoAbsoluto = file.toAbsolutePath();
Path caminhoRelativo = origem.relativize(caminhoAbsoluto);
Path arquivoDestino = destino.resolve(caminhoRelativo.toString());
try {
  Files.createDirectories(arquivoDestino);
  Files.copy(file, arquivoDestino);
} catch (FileAlreadyExistsException ex) {
  //se o diretorio ou arquivo ja existir, nao faz nada (nem sobreescreve)
}

Se quisermos sobre-escrever arquivos já existentes, basta passar o valor StandardCopyOption.REPLACE_EXISTING para o método copy.

Files.copy(file, target, StandardCopyOption.REPLACE_EXISTING);

Poderíamos utilizar uma classe anônima ao invés de ter uma classe que herda de SimpleFileVisitor. Juntando tudo, teríamos:

final Path origem = Paths.get("./src");
final Path destino = Paths.get("./copia");
Files.walkFileTree(origem, new SimpleFileVisitor<Path>() {
  @Override
  public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
    Path caminhoAbsoluto = file.toAbsolutePath();
    Path caminhoRelativo = origem.relativize(caminhoAbsoluto);
    Path arquivoDestino = destino.resolve(caminhoRelativo.toString());
    try {
      Files.createDirectories(arquivoDestino);
    } catch (FileAlreadyExistsException ex) {
      //se o diretorio ja existir, nao faz nada (nem sobreescreve)
    }
    Files.copy(file, arquivoDestino, StandardCopyOption.REPLACE_EXISTING);
    return FileVisitResult.CONTINUE;
  }
});

Fila de Mensagens Mortas

O que acontece quando há uma exceção em um recebedor registrado em uma fila?

Por exemplo:

@MessageDriven(activationConfig = {
  @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "jms/FILA"),
  @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
})
public class RecebedorMDB implements MessageListener {
  public void onMessage(Message msg) {
    throw new RuntimeException("Erro!");
  }
}

A classe acima é um Message Driven Bean (MDB) registrado em FILA que lança uma exceção não checada ao receber uma mensagem.

Se verificarmos a fila, a mensagem foi consumida. Só que aconteceu um erro!

De acordo com a especificação de mensageria do Java EE, o JMS (Java Message Service), um message listener que retorna uma RuntimeException é considerado um erro de programação e terá comportamento indefinido.

Aí entram detalhes da implementação: no HornetQ, o MOM (Message Oriented Middleware) do Wildfly 8.x.x, envia as mensagens que ocasionaram uma exceção para a fila DLQ. O nome vem da sigla para Dead Letter Queue, ou fila de mensagens mortas. É como se fosse um lugar para onde as mensagens vão morrer. O conceito também é conhecido como Dead Letter Channel ou Dead Message Queue.

Mas, na verdade, o recomendado é que os message listeners ou MDBs tratem todas as exceções. Uma boa solução é criarmos DLQs específicas para cada caso excepcional do processo de negócio. Ao detectarmos uma exceção, enviamos a mensagem para a DLQ correspondente.

Métodos default, colisão de interfaces e precedência de superclasses no Java 8

Métodos públicos e abstratos em Interfaces

Imagine que temos a interface Aquatico, que define um método move:

interface Aquatico {
	public abstract void move();
}

Se tivermos uma classe Navio que implementa essa interface mas não fornece uma implementação para o método move, teremos um erro de compilação:

class Navio implements Aquatico {
^
error: Navio is not abstract and does not override abstract method move() in Aquatico
}

Uma interface nos obriga a respeitar um contrato, ou seja, a assinatura (nome, parâmetros e retorno) de um ou mais métodos.

No Java, desde os primórdios, os métodos das interfaces são implicitamente public e abstract. Essa última palavra-chave indica que são métodos abstratos, ou seja, sem corpo definido e sem código, meros moldes a serem preenchidos.

Para o código da classe concreta Navio ser compilado com sucesso, temos que fornecer uma implementação para o método move. Por exemplo:

class Navio implements Aquatico {
	public void move() {
		System.out.println("Navega na água!");
	}
}

O código acima compila normalmente e podemos invocá-lo de maneira polimórfica, como a seguir:

public class Programa {
	public static void main(String[] args){
		Aquatico titanic = new Navio();
		titanic.move(); //imprime "Navega na água!"
	}
}

Métodos com mesma assinatura em Interfaces diferentes

Considere que temos uma interface Terrestre, conforme abaixo:

interface Terrestre {
	public abstract void move();
}

Poderíamos criar um classe Caminhao que implementa a interface Terrestre, de maneira semelhante ao que fizemos acima:

class Caminhao implements Terrestre {
	public void move() {
		System.out.println("Move na longa estrada da vida!");
	}
}

Para utilizar a classe Caminhao, faríamos de maneira parecida com a anterior:

public class Programa {
	public static void main(String[] args){
		Caminhao scania = new Caminhao();
		scania.move(); //imprime "Move na longa estrada da vida!"
	}
}

Mas o que acontece se tivermos uma classe que representa um Hovercraft, um veículo anfíbio, que pode se deslocar tanto na água como na terra?

Será que podemos implementar tanto a interface Aquatico como a interface Terrestre simultaneamente?

Claro que sim, já que a interface define apenas a assinatura (ou seja, nome, parâmetros e retorno) do método move e não uma implementação.

class Hovercraft implements Aquatico, Terrestre {
	public void move(){
		System.out.println("Move na água e na terra!");
	}
}

Não há problema algum, porque a implementação do método move na classe Hovercraft é a mesma tanto para Aquatico como para Terrestre.

Podemos usar a classe Hovercraft conforme a seguir:

public class Programa {
	public static void main(String[] args){
		Hovercraft srn4 = new Hovercraft();
		srn4.move(); //imprime "Move na terra e na água!"
	}
}

Métodos default em Interfaces no Java 8

Conforme vimos em um post anterior, no Java 8 agora é possível definir, além de contratos, implementações de métodos em interfaces.

Esse novo mecanismo é chamado de métodos default e, com ele, é possível evoluir interfaces antigas como a Iterable, que agora possui um método forEach, por exemplo.

No exemplo acima, poderíamos definir o comportamento de navegar na água diretamente na interface Aquatico, utilizando a palavra reservada default:

interface Aquatico {
	public default void move() {
		System.out.println("Navega na água!");
	}
}

Métodos default só podem ser definidos em interfaces e são implicitamente públicos e, é claro, não-abstratos porque possuem um corpo definido, com código.

A classe Navio já não precisará fornercer uma implementação para o método move:

class Navio implements Aquatico {
}	

A interface Terrestre também pode ter uma implementação do método move com um método default:

interface Terrestre {
	public default void move() {
		System.out.println("Move na longa estrada da vida!");
	}
}

A classe Caminhao também seria simplificada:

class Caminhao implements Terrestre {
}

O programa que utiliza as classes Navio e Caminhao, bem como suas respectivas interfaces, não precisa ser alterado:

public class Programa {
	public static void main(String[] args){
		Aquatico titanic = new Navio();
		titanic.move(); //imprime "Navega na água!"

		Caminhao scania = new Caminhao();
		scania.move(); //imprime "Move na longa estrada da vida!"
	}
}

Colisão de métodos default

Mas o que será que acontece com a nossa classe Hovercraft, que implementa tanto Aquatico como Terrestre?

class Hovercraft implements Aquatico, Terrestre {
^
error: class Hovercraft inherits unrelated defaults for move() from types Aquatico and Terrestre

Observe que, para a classe Hovercraft, o código não pode ser compilado. Como com um método default não apenas define uma assinatura mas também uma implementação, há ambiguidade na definição do método move. O compilador não pode definir qual das duas implementações deve ser escolhida e, por isso, nos avisa dessa colisão com um erro de compilação.

Para fazermos a classe Hovercraft compilar com sucesso, temos que definir uma implementação para o método move, evitando qualquer ambiguidade:

class Hovercraft implements Aquatico, Terrestre {
	public void move() {
		System.out.println("Move na terra e na água!");
	}
}

Uma alternativa é invocar um método default de uma interface a partir de uma classe que a implementa, utilizando o nome da interface seguido de super e do nome do método default. Por exemplo:

class Hovercraft implements Aquatico, Terrestre {
	public void move() {
		Aquatico.super.move();
		Terrestre.super.move();
		System.out.println("Move na terra e na água!");
	}
}

Se utilizarmos a classe Hovercraft acima em um programa, teremos algo como:

public class Programa {
	public static void main(String[] args){
		Hovercraft srn4 = new Hovercraft();
		srn4.move(); 
		// imprime 
		//	"Navega na água!"
		//	"Move na longa estrada da vida!"
		//	"Move na terra e na água!"
	}
}

Precedência de métodos da superclasse

Suponha que tenhamos uma interface Aereo, com um método default chamado move:

interface Aereo {
	public default void move() {
		System.out.println("Move no ar!");
	}
}

Também temos uma classe Aviao que implementa a interface Aereo, porém sobreescrevendo o método move:

class Aviao implements Aereo {
	public void move(){
		System.out.println("Voa...");
	}
}

Se criarmos um objeto da classe Aviao, qual método será chamado: o método sobreescrito na classe ou o método default da interface?

Será escolhido o método sobreescrito na classe Aviao, funcionando da mesma maneira que sobreescrita de métodos para classes:

public class Programa {
	public static void main(String[] args){
		Aviao boeing747 = new Aviao();
		boeing747.move(); //imprime "Voa..."
	}
}

Agora, se quisermos representar um Hidroavião, um tipo de avião que pode decolar e pousar na água, teremos uma classe semelhante a seguinte:

class HidroAviao extends Aviao implements Aquatico {
}

A classe HidroAviao é um Aviao que implementa a interface Aquatico.

Mas o que será que acontece ao invocarmos o método move de uma instância de HidroAviao? Será que é invocado a implementação da superclasse Aviao ou da interface Aquatico?

A implementação escolhida será a da superclasse:

public class Programa {
	public static void main(String[] args){
		HidroAviao curtissNC = new HidroAviao();
		curtissNC.move(); //imprime "Voa..."
	}
}

Uma implementação definida em uma superclasse sempre tem precedência sobre uma implementação definida em um método default de uma interface.

É importante lembrar que, em Java, uma classe só pode ter uma superclasse.

Resumindo

As regras do uso de métodos default são bem claras:

  1. Colisão de interfaces – se uma classe implementa duas interfaces que possuem métodos default com a mesma assinatura, o método deve ser sobreescrito
  2. Precedência de superclasses – se uma superclasse provê uma implementação de um método que tem a mesma assinatura de um método default de uma interface, a implementação da superclasse tem precedência

Iteração interna com Java 8 e métodos default

Iterando externamente

Vamos dizer que temos uma lista com nomes de personagens da Disney:

List<String> personagens = Arrays.asList("Pato Donald",
                            "Mickey", "Pateta", "Pluto");

Temos algumas opções para percorrer essa lista e imprimir o conteúdo. A mais intuitiva para iniciantes, é um for:

  for(int i = 0; i < personagens.size(); i++){
    String personagem = personagens.get(i);
    System.out.println(personagem);
  }

Uma opção mais interessante, mas que requer um pouco mais de conhecimento das bibliotecas do Java, é utilizar um Iterator:

  for(Iterator<String> it = personagens.iterator(); it.hasNext();){
    String personagem = it.next();
    System.out.println(personagem);
  }

Ambas as opções, se desconsiderarmos o uso de tipos genéricos, já funcionavam até o Java 4. Porém, do Java 5 em diante, percorrer uma lista ficou mais conciso através do for-each:

  for(String personagem : personagens){
    System.out.println(personagem);
  }

Mesmo com um for-each do Java 5, percorrer uma lista é algo tedioso e repetitivo. Quantas vezes um desenvolvedor Java experiente já escreveu um for desse tipo durante a carreira?

Com esse tipo de código, o desenvolvedor precisa se preocupar em “como” percorrer uma lista ao invés de focar apenas no mais importante: “o que” fazer com os elementos.

Essa maneira clássica, que deixa o “como” a cargo do desenvolvedor, pode ser chamada de iteração externa.

Iterando internamente

Com o Java 8, é possível focar apenas no “o que” fazer com os elementos da lista percorrida, utilizando o método forEach:

personagens.forEach(personagem -> System.out.println(personagem));

Observe que o método forEach pertence à própria lista e recebe um lambda.

Na verdade, pode ser passado qualquer lambda ou classe anônima que atenda à interface funcional Consumer, que recebe um argumento e não retorna resultado.

Poderíamos ter abreviado mais ainda o código utilizando uma referência ao método System.out.println:

personagens.forEach(System.out::println);

Essa maneira nova, que permite ao desenvolvedor focar no “o que” fazer com os elementos, pode ser chamada de iteração interna.

Inserindo implementações em interfaces antigas com métodos default

O método forEach está definido em Iterable e, por consequência, em todos os List, Set e Queue da API de Coleções do Java. Porém, esse método não é abstrato.

O que iria acontecer se colocassem mais um método abstrato na interface Iterable? Código de várias bibliotecas e frameworks por aí, que fornececem suas próprias implementações para essas classes, iriam deixar de funcionar. E o Java tem como um de seus princípios mais fortes a retrocompatibilidade e evolução suave (para muitos, suave até demais).

Para evitar qualquer quebra inaceitável, foi criada uma implementação concreta na interface Iterable para o método forEach. Como foi possível inserir uma implementação em uma interface? Antes do Java 8, as interfaces só podiam ter métodos públicos e abstratos, afinal de contas…

Foi criado um novo mecanismo: os métodos default. Para definir um método default, criamos um método com a palavra-chave default e, em seguida, fornecemos uma implementação para o método.

Veja o que aconteceu com a interface Iterable:

package java.lang;

//imports ...

public interface Iterable<T> {

  Iterator<T> iterator(); //método implicitamente 
                          //abstrato e público 

  default void forEach(Consumer<? super T> action) {
    Objects.requireNonNull(action);
      for (T t : this) {
        action.accept(t);
      }
  }

  //...
}

Métodos default permitem evoluir uma API antiga de maneira não disruptiva, sem romper com o passado. A implementação definida em uma método default é “copiada” para todas as classes que implementam essa interface. Em um próximo post, veremos com mais detalhes como funciona esse mecanismo.

Métodos default acabaram com a prática comum de ter uma interface acompanhada de uma superclasse abstrata que fornece implementações para a maioria dos métodos e deixando apenas detalhes para as subclasses concretas.

Um exemplo disso é o par List e AbstractList. Agora, se fossemos reprojetar a API de Coleções do Java, poderíamos colocar boa parte do código de AbstractList como métodos default da interface List.

O código desse post pode ser encontrado em: https://gist.github.com/alexandreaquiles/9753849

Evitando duplicação com Strategy e Classes Anônimas

Suponha que temos a seguinte classe Desenho:

class Desenho {

	private final String nome;
	private final int decadaDeCriacao;

	public Desenho(String nome, int decadaDeCriacao) {
		this.nome = nome;
		this.decadaDeCriacao = decadaDeCriacao;
	}

	public String getNome() {
		return nome;
	}

	public int getDecadaDeCriacao() {
		return decadaDeCriacao;
	}
	
	public String toString() {
		return nome + " (" + decadaDeCriacao + ")";
	}
}

Com a classe Desenho em mãos, vamos criar uma classe principal e alguns desenhos, colocando-os em uma lista:

class Programa {
	public static void main(String[] args) {
		Desenho popeye = new Desenho("Popeye", 1920);
		Desenho picaPau = new Desenho("Pica-pau", 1940);
		Desenho flintstones = new Desenho("Flintstones", 1960);
		Desenho scoobyDoo = new Desenho("Scooby-Doo", 1970);
		Desenho simpsons = new Desenho("Simpsons", 1990);
                
		List<Desenho> desenhos = 
                Arrays.asList(popeye, picaPau, 
                            flintstones, scoobyDoo, simpsons);
	}
}

Essa lista de desenhos poderia, ao invés de ser criada na mão, vir de um banco de dados através de uma DAO.

Dentro da main, vamos filtrar todos os desenhos que foram criados antes de 1960 e imprimi-los:

List<Desenho> antesDe1960 = new ArrayList<>();
for (Desenho desenho : desenhos) {
	if(desenho.getDecadaDeCriacao() < 1960){
		antesDe1960.add(desenho);
	}
}
for (Desenho desenho : antesDe1960) {
	System.out.println(desenho);
}

Deverá ser impresso:

Popeye (1920)
Pica-pau (1940)

E se quisermos filtrar todos os desenhos que começam com a letra “S”? Faríamos algo como:

List<Desenho> comecamComS = new ArrayList<>();
for (Desenho desenho : desenhos) {
	if(desenho.getNome().startsWith("S")){
		comecamComS.add(desenho);
	}
}
for (Desenho desenho : comecamComS) {
	System.out.println(desenho);
}

Teríamos a seguinte saída:

Scooby-Doo (1970)
Simpsons (1990)

Observem acima as linhas destacadas no código dos dois filtros. São as únicas linhas essenciais, com código que tem a ver com o que realmente queremos fazer: filtrar os desenhos.

O resto é código repetitivo, apenas dá suporte ao que queremos fazer. E esse código de suporte tem exatamente a mesma estrutura nos dois exemplos. Código duplicado, a raiz de todo o mal!

Evitando duplicação com Strategy e Classes Anônimas

Podemos evitar esse tipo de duplicação extraindo o código repetitivo para uma classe que filtra os desenhos:

class FiltroDeDesenhos {
	public List<Desenho> filtra(List<Desenho> desenhos){
		List<Desenho> filtrados = new ArrayList<>();
		for (Desenho desenho : desenhos) {
			if(???){
				filtrados.add(desenho);
			}
		}
		return filtrados;
	}
}

Mas a comparação vai variar de acordo com o que quisermos filtrar. E agora?

Podemos utilizar um molde chamado Strategy, de maneira a isolarmos as diferentes comparações cada uma em uma classe própria, respeitando um contrato comum.

Para definir um contrato em Java, utilizamos uma interface:

interface ComparacaoDeDesenhos {
	boolean valePara(Desenho desenho);
}

Devemos colocar a interface ComparacaoDeDesenhos como parâmetro do método filtra de FiltroDeDesenhos, usando-a para encapsular a lógica de filtragem dos desenhos de maneira polimórfica:

class FiltroDeDesenhos {
	public List<Desenho> filtra(List<Desenho> desenhos, 
				ComparacaoDeDesenhos comparacao){
		List<Desenho> filtrados = new ArrayList<>();
		for (Desenho desenho : desenhos) {
			if(comparacao.valePara(desenho)){
				filtrados.add(desenho);
			}
		}
		return filtrados;
	}
}

Para utilizarmos a nossa nova classe FiltroDeDesenhos para filtrar os desenhos criados antes de 1960, precisaríamos criar uma classe que atenda ao contrato definido pela interface ComparacaoDeDesenhos:

class ComparacaoDeDesenhosAntesDe1960 
				implements ComparacaoDeDesenhos {
	public boolean valePara(Desenho desenho) {
		return desenho.getDecadaDeCriacao() < 1960;
	}
} 

Então, poderíamos cria uma instância da nossa nova classe ComparacaoDeDesenhosAntesDe1960, e passá-la para o nosso FiltroDeDesenhos, depois imprimindo os desenhos filtrados:

FiltroDeDesenhos filtro = new FiltroDeDesenhos();

ComparacaoDeDesenhos comparacaoDeDesenhosAntesDe1960 = 
					new ComparacaoDeDesenhosAntesDe1960();

List<Desenho> antesDe1960 = filtro.filtra(desenhos, 
					comparacaoDeDesenhosAntesDe1960);
for (Desenho desenho : antesDe1960) {
       	System.out.println(desenho);
}

A saída seria a mesma de antes:

Popeye (1920)
Pica-pau (1940)

Para filtrar os desenhos que começam com “S”, teríamos que criar a classe ComparacaoDeDesenhosQueComecamComS.

Mas será que, pra todo o tipo de comparação, temos que criar uma classe diferente? Se fosse assim, o número de classes ia ser imenso.

Ao invés de criar a classe ComparacaoDeDesenhosAntesDe1960, poderíamos criar uma instância de uma classe sem nome, que atende à interface ComparacaoDeDesenhos, tudo de uma vez:

FiltroDeDesenhos filtro = new FiltroDeDesenhos();

List<Desenho> antesDe1960 = filtro.filtra(desenhos, 
	new ComparacaoDeDesenhos() {
		public boolean valePara(Desenho desenho) {
			return desenho.getDecadaDeCriacao() < 1960;
		}
});
for (Desenho desenho : antesDe1960) {
       	System.out.println(desenho);
}

Continuaríamos com a mesma saída:

Popeye (1920)
Pica-pau (1940)

Observe demos um new na interface ComparacaoDeDesenhos, seguido de uma implementação do método valePara, sem fornecer um nome para a classe.

Ao criarmos uma implementação de uma interface que não tem nome, estamos criando uma classe anônima.

O trio “});” é bem familiar para quem usa Javascript, já que aparece nas funções de callback usadas por muitas bibliotecas.

Para filtrar todos os desenhos que começam com “S”, faríamos:

List<Desenho> comecamComS = filtro.filtra(desenhos, 
	new ComparacaoDeDesenhos() {
		public boolean valePara(Desenho desenho) {
			return desenho.getNome().startsWith("S");
		}
});
for (Desenho desenho : comecamComS) {
	System.out.println(desenho);
}

Teríamos exatamente a mesma saída de antes:

Scooby-Doo (1970)
Simpsons (1990)

Comparando as implementações

Se deixarmos a impressão dos desenhos filtrados de fora, teríamos o seguinte código antes do uso de Strategy com classes anônimas:

List<Desenho> antesDe1960 = new ArrayList<>();
for (Desenho desenho : desenhos) {
       	if(desenho.getDecadaDeCriacao() < 1960){
       		antesDe1960.add(desenho);
       	}
}
List<Desenho> comecamComS = new ArrayList<>();
for (Desenho desenho : desenhos) {
       	if(desenho.getNome().startsWith("S")){
       		comecamComS.add(desenho);
       	}
}

Já o código com Strategy e classes anônimas, ficou assim:

List<Desenho> antesDe1960 = filtro.filtra(desenhos, 
	new ComparacaoDeDesenhos() {
		public boolean valePara(Desenho desenho) {
			return desenho.getDecadaDeCriacao() < 1960;
		}
});
List<Desenho> comecamComS = filtro.filtra(desenhos, 
	new ComparacaoDeDesenhos() {
		public boolean valePara(Desenho desenho) {
			return desenho.getNome().startsWith("S");
		}
});

O número de linhas ficou o mesmo, mas a modelagem da solução ficou melhor, evitando repetição do laço e do acúmulo dos desenhos filtrados em uma nova lista.

Uso de Strategy e Classes Anônimas em bibliotecas

É muito comum em bibliotecas do mundo Java utilizar o molde Strategy com classes anônimas.

Um exemplo bem comum é a interface Comparator da API de Collections do Java:

Collections.sort(desenhos, new Comparator<Desenho>() {
	public int compare(Desenho desenho1, Desenho desenho2) {
		return desenho1.getNome()
				.compareTo(desenho2.getNome());
	}
});
for (Desenho desenho : desenhos) {
	System.out.println(desenho);
}

O código acima, irá imprimir os desenhos ordenados por nome:

Flintstones (1960)
Pica-pau (1940)
Popeye (1920)
Scooby-Doo (1970)
Simpsons (1990)

Em frameworks como Spring, o uso de Strategy e classes anônimas é bastante comum. É usado, por exemplo, para gerenciar uma transação programaticamente:

transactionTemplate.execute(new TransactionCallback() {
	// código executado em uma transação
	public Object doInTransaction(TransactionStatus status) {
 		atualizarPedidos(compra.getPedidos());
		return atualizarTotalDaCompra(compra);
 	}
});

Concluindo

Através do uso de Strategy e classes anônimas, conseguimos criar uma solução que encapsula a estrutura, permitindo-nos focar na essência do que estamos fazendo e, dessa maneira, evitando duplicação.

Essa solução é bastante usada em bibliotecas e frameworks do mundo Java.

Porém, a sintaxe de classes anônimas em Java é assustadora.

No próximo post, veremos o que o Java 8 tem a oferecer para deixar nosso código mais sucinto.

O código desse post pode ser encontrado em: https://gist.github.com/alexandreaquiles/9644356

Sequências Infinitas em Scala e Java

Sequências Infinitas?

Em um workshop com o pessoal do trabalho, iríamos começar mais uma implementação de Fibonacci.

Acabamos definindo uma API parecida com a abaixo:

public List<Integer> fibonacci();

Porém, para conseguir fazer algo do gênero, é necessária uma maneira de representar uma sequência infinita de valores.

No workshop, como precisávamos de foco, mudamos a API para receber um número e retornar o número de Fibonacci correspondente.

Só que há uma maneira de representar essa sequência infinita em um computador…

Fibonacci?

Só para lembrar,  conforme está descrito na Wikipedia, a sequência de Fibonacci “é uma sequência de números naturais, na qual os primeiros dois termos são 0 e 1, e cada termo subsequente corresponde à soma dos dois precedentes”.

Lazy Evaluation

Na teoria de linguagens de programação, há o conceito de Lazy Evaluation, em que o runtime adia a avaliação de um trecho de código até quando esse código realmente precisar ser executado.

Esse conceito está presente principalmente em Programação Funcional, em linguagens como Haskell, Scheme ou Scala.

Em Scala

Com a linguagem de programação Scala, é possível criar uma  uma função recursiva que calcula a sequência de Fibonacci em que não há condição de parada!

def fibonacciSequence : Stream[Long] = {
    def fibonacciFrom(a: Long, b: Long) : Stream[Long] = a #:: fibonacciFrom(b, a+b)
    fibonacciFrom(0, 1)
}

Mas como isso é possível? Como o código acima não entra em recursão infinita até gerar um StackOverflowError?

No código acima, é utilizada uma estrutura de dados chamada Stream, que é uma lista cuja avaliação da concatenação (o #::) é lazy. Por isso, a chamada recursiva só é feita quando realmente é necessária.

Se chamarmos diretamente a função fibonacciSequence a partir do REPL do Scala será retornado:

scala> fibonacciSequence
> res0: scala.collection.immutable.Stream[Long] = Stream(0, ?)

Observe que só o primeiro valor, que no caso é 0, será retornado. O resto da sequência ainda não foi avaliado, o que é representado como ?.

Se utilizarmos a função take para pegarmos os 5 primeiros valores dessa sequência, ainda assim apenas o primeiro valor é avaliado:

scala> fibonacciSequence take 5
> res1: scala.collection.immutable.Stream[Long] = Stream(0, ?)

Para realmente avaliar os valores, temos que utilizá-los, por exemplo, tranformando para uma lista que não é lazy com um toList ou percorrendo-os com um foreach:

scala> fibonacciSequence take 5 toList
> res2: List[Long] = List(0, 1, 1, 2, 3)

scala> fibonacciSequence take 5 foreach println
> 0
| 1
| 1
| 2
| 3

Em Java

Recentemente, o polêmico Uncle Bob tem escrito sobre como utilizar conceito de Programação Funcional em Java e tem recebido diversas críticas.

Em um de seus artigos, Uncle Bob mostrou como utilizar lazy evaluation em Java utilizando um Iterator. Há um exemplo mostrando o uso de Iterator para criar uma sequência infinita de inteiros elevados ao quadrado.

Na verdade, Neal Ford já havia mostrado como usar um Iterator para obter lazyness com Java. O exemplo utilizado foi o cálculo de números primos.

Com Iterator

Através da técnica do Iterator, é possível fazer um código bem simples para gerar uma sequância “infinita” com os números de Fibonacci:

public class FibonacciSequence implements Iterator<Long> {
    private long n = 0;
    private long a = 0;
    private long b = 1;

    public boolean hasNext() { return a + b > 0; }

    public Long next() {
        long fib;
        if(n == 0 || n == 1) {
            fib = n;
        }
        else {
            fib = a + b;
            a = b;
            b = fib;
        }
        n++;
        return fib;
    }

    public void remove() {}
}

As variáveis a e b armazenam os valores de Fibonacci dos números anteriores. O número atual é mantido na variável n.

Os dois primeiros valores da sequência 0 e 1, são retornados diretamente, sem atualizar as variáveis a e b.

O Fibonacci de um dado número n é a soma dos números de Fibonacci precedentes, portando é a + b.  Para preparar a sequência para os próximos valores, as variáveis a e b são atualizadas com o número de Fibonacci anterior e o atual, respectivamente.

A implementação do método hasNext considera se a soma de a + b ainda é positiva, para evitar Integer Overflow, o que faria com que os números a e b ficassem com valores negativos.

Podemos utilizar o código acima, por exemplo, para pegar os 10 primeiros números na sequência:

FibonacciSequence fs = new FibonacciSequence();
for(int i = 0; i < 10 && fs.hasNext(); i++){
    System.out.println(fs.next());
}

Podemos criar o objeto Taker criado por Uncle Bob para simular a função take do Scala:

public class Taker<T> {
    public List<T> take(int n, Iterator<T> xs) {
        List<T> taken = new ArrayList<T>();
        for (int i = 0; xs.hasNext() && i < n; i++) {
           taken.add(xs.next());
        }
        return taken;
    }
}

Se utilizarmos o Taker para gerar a sequência dos 25 primeiros números de Fibonacci, teríamos o seguinte código:

List<Long> fibonacciUpto25 = new Taker<Long>().take(25, new FibonacciSequence());

Com Functional Java

A biblioteca Functional Java tem uma estrutura de dados Stream parecida com a do Scala, que permite lazy evaluation.

Baseados em um exemplo da documentação da biblioteca, poderíamos definir uma variável no nosso programa que contém a sequência de Fibonacci:

public static final Stream<Long> fibonacciSequence = new F2<Long, Long, Stream<Long>>() {
    public Stream<Long> f(final Long a, final Long b) {
        return Stream.cons(a, curry().f(b).lazy().f(a + b));
    }
}.f(0L, 1L);

O método cons da classe Stream é correspondente ao #:: do Scala.

A classe Stream provê um método take. Assim, para obter nossa lista com os 25 primeiros números da sequência de Fibonacci:

List<Long> fibonacciUpto25 = fibonacciSequence.take(25).toList();

Com Totally Lazy

Já a biblioteca Totally Lazy tem uma função embutida na classe Numbers que gera a sequência de Fibonacci. Essa função é implementada da seguinte forma:

public static Sequence<Number> fibonacciSequence  =
computation(Pair.<Number, Number> pair(0, 1), reduceLeftShift(sum)).map(first(Number.class));

Para obter nossos 25 primeiros números de Fibonacci:

List<Number> fibonacciUpto25 = fibonacciSequence.take(25).toList();

A abordagem do Totally Lazy é bem diferente das demais.  Observe que a classe Number é utilizada, ao invés de Long.