Programando Java

VRaptor 3 - Poupando recursos - LAZY Dependence Injection

2009-10-20T07:41:00.007-03:00

Objetivo: Ao final deste artigo espera-se que você saiba como poupar recursos caros, trazendo eles de forma LAZY, ou como prefiro chamar Just-in-Time (no momento certo).

No VRaptor3 a injeção de dependencia ficou bem mais fácil, os interceptadores que eram os responsáveis para injetar a dependencia sumiram e agora fica tudo a cargo do container, que pode ser o Spring ou o Pico.

A facilidade na injeção de dependencia tem um custo, como não é mais controlado pelo programador que cria o interceptor sempre que declaramos uma dependencia no construtor de um @Component, @Resource ou @Intercepts ele é injetado no inicio, logo na construção, porem as vezes o fluxo de um requisição faz com que não usemos algumas destas injeções de dependencia, disperdiçando recursos valiosos.

Por exemplo, vamos supor o seguinte @Resource abaixo, que cadastra produtos

import java.util.List;
 
import org.hibernate.Session;
 
import br.com.caelum.vraptor.Result;
import br.com.caelum.vraptor.view.Results;
 
public class ProdutoController {
        /**
         * O recurso que queremos poupar.
         */
        private final Session session;
        private final Result result;
        
        public ProdutoController(final Session session, final Result result) {
                this.session = session;
                this.result = result;
        }
        
        /** 
         * apenas renderiza o formulário
         */
        public void form() {}
        
        public List<Produto> listar() {
                return session.createCriteria(Produto.class).list();
        }
        
        public Produto adiciona(Produto produto) {
                session.persist(produto);
                result.use(Results.logic()).redirectTo(getClass()).listar();
                return produto;
        }
}

Sempre que alguem faz uma requisição a qualquer lógica dentro do recurso ProdutoController uma Session é aberta, porem note que abrir o formulário para adicionar produtos não requer sessão com o banco, ele apenas renderiza uma página, cada vez que o formulário de produtos é aberto um importante e caro recurso do sistema esta sendo requerido, e de forma totalmente ociosa.

Como agir neste caso ? isolar o formulário poderia resolver este problema mais recairia em outro, da mantenabilidade.

O ideal é que este recurso só fosse realmente injetado no tempo certo (Just in Time) como seria possivel fazer isso ? a solução é usar proxy dinamicos, enviando uma session que só realmente abrirá a conexão com o banco quando um de seus métodos for invocado

import java.lang.reflect.Method;
 
import javax.annotation.PreDestroy;
import org.hibernate.classic.Session;
import org.hibernate.SessionFactory;
 
import net.vidageek.mirror.dsl.Mirror;
 
import br.com.caelum.vraptor.ioc.ApplicationScoped;
import br.com.caelum.vraptor.ioc.Component;
import br.com.caelum.vraptor.ioc.ComponentFactory;
import br.com.caelum.vraptor.ioc.RequestScoped;
import br.com.caelum.vraptor.proxy.MethodInvocation;
import br.com.caelum.vraptor.proxy.Proxifier;
import br.com.caelum.vraptor.proxy.SuperMethod;
 
/**
 * <b>JIT (Just-in-Time) {@link Session} Creator</b> fábrica para o componente {@link Session}
 * gerado de forma LAZY ou JIT(Just-in-Time) a partir de uma {@link SessionFactory}, que
 * normalmente se encontra em um ecopo de aplicativo @{@link ApplicationScoped}.
 * 
 * @author Tomaz Lavieri
 * @since 1.0
 */
@Component
@RequestScoped
public class JITSessionCreator implements ComponentFactory<Session> {
        
    private static final Method CLOSE = new Mirror().on(Session.class).reflect().method("close").withoutArgs();
    private static final Method FINALIZE = new Mirror().on(Object.class).reflect().method("finalize").withoutArgs();
    private final SessionFactory factory;
    /** Guarda a Proxy Session */
        private final Session proxy;
        /** Guarada a Session real. */
        private Session session;
        
        public JITSessionCreator(final SessionFactory factory, final Proxifier proxifier) {
                this.factory = factory;
                this.proxy = proxify(Session.class, proxifier); // *1*
        }
        
        /**
         * Cria o JIT Session, que repassa a invocação de qualquer método, exceto 
         * {@link Object#finalize()} e {@link Session#close()}, para uma session real, criando 
         * uma se necessário.
         */
        private Session proxify(Class<? extends Session> target, Proxifier proxifier) {
                return proxifier.proxify(target, new MethodInvocation<Session>() {
                    @Override // *2*
                    public Object intercept(Session proxy, Method method, Object[] args, SuperMethod superMethod) {
                        if (method.equals(CLOSE) || (method.equals(FINALIZE) && session == null)) {
                            return null; //skip
                        }
                        return new Mirror().on(getSession()).invoke().method(method).withArgs(args);
                    }
                });
        }
        
        public Session getSession() {
                if (session == null) // *3*
                        session =       factory.openSession();
                return session;
        }
        
        @Override
        public Session getInstance() {
                return proxy; // *4*
        }
        
        @PreDestroy
        public void destroy() { // *5*
                if (session != null && session.isOpen()) {
                        session.close();
                }
        }
}

Explicando alguns pontos chaves, comentados com // *N*

O Proxfier é um objeto das libs do vrapor que auxilia na criação de objetos proxys ele é responsável por escolher a biblioteca que implementa o proxy dinamico, e então invocar via callback um método interceptor, como falamo abaixo.

Neste ponto temos a implementação do nosso interceptor, sempre que um método for envocado em nosso proxy, esse intereptor é invocado primeiro, ele filtra as chamada ao método finalize caso a session real ainda não tenha sido criada, isso evita criar a session apenas para finaliza-la.
O método close também é filtrao, isso é feito para evitar criar uma session apenas para fecha-la, e também por que o nosso SessionCreator é que é o responsavel por fechar a session ao final do scopo, quando a request acabar.
Todos os outros métodos são repassados para uma session através do método getSession() onde é realmente que acontece o LAZY ou JIT.

Aqui é onde acontece a mágia, da primeira vez que getSession() é invocado a sessão é criada, e então repassada, todas as outras chamadas a getSession() repassam a sessão anteriormente criada, assim, se getSession() nunca for envocado, ou seja, se nenhum método for envocado no proxy, getSession() nunca será invocado, e a sessão real não será criada.

O retorno desse ComponentFactory é a Session proxy, que só criará a session real se um de seus métodos for invocado.

Ao final do escopo o destroy é invocado, ele verifica se a session real existe, existindo verifica se esta ainda esta aberta, e estando ele fecha, desta forma é possivel garantir que o recurso será sempre liberado.

Assim podemos agora pedir uma session sempre que acharmos que vamos precisar de uma, sabendo que o recurso só será realmente solicitado quando formos usar um de seus métodos, salvando assim o recurso.

Esta mesma abordagem pode ser usada para outros recursos caros do sistema.

Os códigos fonte para os ComponentFactory de EntityManager e Session que utilizo podem ser encontrados neste link: http://guj.com.br/posts/list/141500.java

VRaptor3 - Interceptando recursos anotados

2009-10-17T17:01:00.012-03:00

Em primeira lugar, gostaria de tecer meus mais sinceros elogios a equipe VRaptor, a versão 3 esta muito boa, bem mais intuitiva e fácil de usar que a 2.6

Neste artigo vou mostar como interceptar um método de um Resource especifico, identificando-o a partir de uma anotação e executar ações antes do método executar, e após ele executar.

Vamos supor que nós temos o seguinte Resource para adicionar produtos no nosso sistema

@Resource
public class ProdutoController {
        private final DaoFactory factory;
        private final ProdutoDao dao;
        
        public ProdutoController(DaoFactory factory) {
                this.factory = factory;
                this.dao = factory.getProdutoDao();
        }
        
        public List<Produto> listar() {
                return dao.list();
        }
        
        public Produto atualizar(Produto produto) {
                try {
                        factory.beginTransaction();
                        produto = dao.update(produto);
                        factory.commit();
                        return produto;
                } catch (DaoException ex) {
                        factory.rollback();
                        throw ex;
                }
        }
        
        public Produto adicionar(Produto produto) {
                try {
                        factory.beginTransaction();
                        produto = dao.store(produto);
                        factory.commit();
                        return produto;
                } catch (DaoException ex) {
                        factory.rollback();
                        throw ex;
                }
        }
}

Agora nos queremos que um interceptador intercepte meu recurso, e execute a lógica dentro de um escopo transacional, como fazer isso ? é só criar um interceptador assim.

import org.hibernate.Session;
import org.hibernate.Transaction;
 
import br.com.caelum.vraptor.Intercepts;
import br.com.caelum.vraptor.core.InterceptorStack;
import br.com.caelum.vraptor.interceptor.Interceptor;
import br.com.caelum.vraptor.resource.ResourceMethod;
 
@Intercepts
public class TransactionInterceptor implements Interceptor {
        private final Session session;
        public TransactionInterceptor(Session session) {
                this.session = session;
        }
        public void intercept(InterceptorStack stack, ResourceMethod method, Object instance) {
                Transaction transaction = null;
                try {
                        transaction = session.beginTransaction();
                        stack.next(method, instance);
                        transaction.commit();
                } finally {
                        if (transaction != null && transaction.isActive()) {
                                transaction.rollback();
                        }
                }
        }
        public boolean accepts(ResourceMethod method) {
                return true; //aceita todas as requisições
        }
}

Ok, o interceptador vai rodar e abrir transação antes e depois de executar a logica, e os métodos transacionais da minha lógica irão se reduzir a isto

public Produto atualizar(Produto produto) {
        return dao.update(produto);
}
 
public Produto adicionar(Produto produto) {
        return dao.store(produto);
}

Ok mas, neste caso temos o problema de que métodos que não exigem transação estão abrindo e fechando transação a cada requisição sem necessidade.

Como então selecionar apenas algumas lógicas para serem transacionais ? podem criar uma anotação para isto, desta forma:

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
 
/**
 * Usado para garantir que um determinado recurso interceptado seja executada em um
 * escopo de tranzação.
 * @author Tomaz Lavieri
 * @since 1.0
 */
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD,ElementType.TYPE})
public @interface Transactional {}

Agora precisamos marcar os pontos onde queremos que o escopo seja transacional com esta anotação.

@Resource
public class ProdutoController {
        private final ProdutoDao dao;
        
        public ProdutoController(ProdutoDao dao) {
                this.dao = dao;
        }
        
        public List<Produto> listar() {
                return dao.list();
        }
        
        @Transactional
        public Produto atualizar(Produto produto) {
                return dao.update(produto);
        }
        
        @Transactional
        public Produto adicionar(Produto produto) {
                return dao.store(produto);
        }
}

Ok o código ficou bem mais enxuto, mas como interceptar apenas os métodos marcados com esta anotação ?? para tal basta no nosso accepts do TransactionInterceptor verificarmos se a anotação esta presente no método, ou no proprio rescurso (quando marcado no recurso todos os métodos do recurso seriam transacionais).

A modificação do método ficaria assim

        public boolean accepts(ResourceMethod method) {
                return  method 
                                .getMethod() //metodo anotado
                                .isAnnotationPresent(Transactional.class) 
                        || method
                                .getResource() //ou recurso anotado
                                .getType() 
                                .isAnnotationPresent(Transactional.class);
        }

Pronto agora somente os métodos com a anotação @Transacional são executados em escopo de transação e economisamos linhas e linhas de códigos de try{commit}catch{rollback throw ex}

Apresentação Java Collection

2009-09-19T10:15:00.007-03:00

No dia 18/09/2009 falei no SUN DAY da Semana de computação da UFPB sobre Java Collection.

Os arquivos usados na apresentação seguem logo abaixo.

Collections: Apresentação usada no Sun Day
Diagrama de Escolha
Diagrama de Agrupamento

Apresentação original, feita para o grupo de estudos
Collections e Generics: Apresentação no Grupo de estudos

meu twitter:
http://twitter.com/tomazlavieri

Fotos do evento:

Collection e Generics

2009-07-17T15:06:00.003-03:00

Ultima apresentação que fiz para o Grupo de SCJP referencte a Collections e Generics

Em breve posto mais detalhes.

para baixar a apresentação sem se cadastrar no SlideShare slides em pdf

Collections E Generics

View more documents from lavieri.

SCJP - Exercicio sobre Garbage Collector

2009-06-04T20:19:00.003-03:00

A pedido de um colega, fiz um pequeno Slide, mostrando como resolver exercícios para a Certificação SCJP 6 sobre Garbage Collector.

SCJP 6 - Garbage Collector

View more Microsoft Word documents from lavieri.

O pdf pode ser baixado aqui.

Obs.: prometo que muito em breve dou uma revisada, para melhorar o portugues da apresentação.

SCJP 6.0 passei com 90%

2009-06-02T23:51:00.002-03:00

Bom pessoal, passei os últimos 45 dias, ocupado, escutando para o SCJP e por isso não postei mais, a partir de agora, pretendo retomar os posts... segue um pequeno resumo da trajetória que fiz para a certificação.

Fiz hoje cedo o exame em recife,

foi bem tranquilo, tirando que não tive muito paciencia de fazer a revisão, e devo ter errado em questões por desatenção, pois anotei todas as questões que tive duvida, real, e depois da prova conferi que minhas suposições foram corretas ^^...

Fiz o score de 90% divido conforme abaixo...

view plaincopy to clipboardprint?
/* 
- Declarations, Initialization and Scoping .... 91% 
- Flow Control ................................ 90% 
- API Contents ................................ 90% 
- Concurrency ................................ 100% 
- OO Concepts ................................ 100% 
- Collections / Generics ...................... 90% 
- Fundamentals ................................ 72% 
*/  

Comecei a esudar 14/04/2009 quando comprei o livro => http://www.guj.com.br/posts/list/123655.java

Estudei pelo livro da Kathy, SCJP 6, fiz todos os exercicios

cap 01 -> . 100%
cap 02 -> .. 80%
cap 03 -> . 100%
cap 04 -> .. 90%
cap 05 -> .. 94%
cap 06 -> .. 80%
cap 07 -> .. 94%
cap 08 -> .. 92%
cap 09 -> .. 94%
cap 10 -> .. 83%

.........
Ai fiz um Mock (bem fraco por sinal) do javaranch, que tem varias questões fora do escopo da prova, que acertei 92%
http://www.javaprepare.com/quests/test.html

Ai fiz o exame do Inquisition-0.14 ... o de 82 questões, acertei 94% .. fiz os outros exames menores também, que acertei por volta de 90%

Depois fiz 2 provas sorteadas no Testkiller (72 questões cada prova) 92% na primeira, e 96% na segunda

em seguida nos dois dia antes do exame fiz 2 provas do ExamLab for SCJP6, que achei o melhor dos exames, principalmente, pq é muito semelhante a prova, o mais proximo a prova original... tirei + de 94% na primeira e 92% na segunda... (a engine é semelhante, mais o nivel é mais dificil)...

e hoje pela manha fiz a prova, enfim, agora é batalhar por experiencia profissional, e passar para as proximas certificações

e foi isso

Igualdade em java - equals() e hashCode()

2009-04-02T15:47:00.012-03:00

Um dos maiores problemas que os programadores encontram ao inciar seu trabalho em java é o de entender os testes de igualdade.

A igualdade em java não pode ser testada através do operador == , estes operador apenas verifica se duas variaveis fazem referencia a mesma instancia de um objetos.

Para ser um pouco mais claro, imaginemos uma classe Pessoa, como segue abaixo.

public class Pessoa {
    private String nome;
    private String cpf;
    private Integer idade;
    
    public Pessoa(String nome, String cpf) {
        this.nome = nome;
        this.cpf = cpf;
    }
    
    public Integer getIdade() {
        return idade;
    }
    
    public void setIdade(Integer idade) {
        this.idade = idade;
    }
 
    public String getNome() {
        return nome;
    }
    
    public String getCpf() {
        return cpf;
    }
}

Como posso eu falar que duas pessoas são as mesmas pessoas ? a JVM (Java Virutal Machine) por se só não tem como identificar como duas pessoas podem ser ditas iguais, desta forma o teste abaixo, verifica apenas se estas são instancias de um mesmo objeto.

Pessoa maria = new Pessoa("Maria da Silva","111.222.333-44");
maria.setIdade(15);
 
Pessoa mariaDaSilva = new Pessoa("Maria da Silva","333.555.222-11");
mariaDaSilva.setIdade(40);
 
//apesar dos nomes iguais de maria e mariaDaSilva, os cpfs são
//diferentes e desta forma posso falar que são pessoas diferentes
 
Pessoa mariaDaSilva2 = new Pessoa("Maria da Silva","333.555.222-11");
 
//mariaDaSilva e mariaDaSilva2 são pessoas iguais, e mesmo não setando
//a idade de mariaDaSilva2, em um teste de igualdade eu vou querer que
//para esses 2 objetos ele seja positivo.
 
//porem são 2 instancias de de objetos diferentes, portanto
 
boolean referencia = mariaDaSilva == mariaDaSilva2;
 
System.out.println("Referencia é falso (" + referencia + ")");
//isso ocorre pq:
//a variável mariaDaSilva aponta para um objeto enquanto
//a variável mariaDaSilva2 aponta para outro objeto.

Equals:

Para resolver esse problema em java existe um mecanismo de igualdade que vem em todo objeto, e descende da classe Object, onde vc pode testar a igualdade entre objetos através de: primeiroObjeto.equals(segundoObjeto); este teste, quando não sobrescrito apenas testa se os 2 objetos são referencia de uma mesma instancia, ou seja, tem o mesmo efeito que primeiroObjeto == segundoObjeto;.

Antes de implementar um equals em nossos objetos é preciso saber de cinco regras.
Equals...

É reflexivo: para qualquer qualquer referencia não nula a, a.equals(a) tem sempre que ser verdadeiro, ou seja, um objeto é sempre igual a se mesmo.

É simétrico: para quaisquer referencias não nulas de a e b, a.equals(b) so poderá retornar verdade se b.equals(a) retornar verdade, o mesmo raciocinio vale para falso.

É transitivo: para quisquer referencias não nulas de a,b e c, se a.equals(b) e b.equals(c) são verdade então também tem que ser verdade que a.equals(c).

É consistente - para quaisquer referencias não nulas de a e b, multiplas invocações de a.equals(b) terá sempre que retornar true ou sempre retornar false, enquanto informações usadas na comparação do equals não sejam alteradas.

O resultado de equals() entre um objeto e nulo deve retornar sempre falso, a.equals(null) é sempre falso.

Com essa ideia podemos pensar em como implementar o equals para nossa classe Pessoa, sabemos que, duas Pessoas de mesmo nome podem ser diferente, portanto esse não pode ser nosso parametro para teste. Duas pessoas não podem ter o mesmo número de CPF, então este número é unico, e pode identificar uma pessoa, sendo assim nosso teste de igualdade entre duas pessoa pode ser

@Override
public boolean equals(Object obj) {
    if (obj == null) {
        return false; //nenhum objeto pode ser igual a null
    }
    if (!obj instanceof Pessoa) { //uma pessoa só pode ser igual a outra pessoa
        return false;
    }
    final Pessoa other = (Pessoa) obj;
    if (getCpf() == null) //se não houver CPF não há como testar as duas pessoas.
        return false;
    return getCpf().equals(other.getCpf()); //duas pessoas serão iguais...
                                            //se seus CPFs forem iguais...
}

HashCode:

Assim como há um teste de igualdade, Java ainda dispoem de outro teste, onde é possivel rapidamente, através de integer, restringir o campo de igualdade, através de hashCode(). assim como equals, o hashCode segue um contrato descrito abaixo:

É constante: A qualquer momento durante a excecução de um programa java, o método hashCode deve constantemente retornar o mesmo inteiro, enquanto informações usadas na comparação do equals não sejam alteradas. O hashCode não precisa ser constante de uma execução da aplicação para outra.

Se dois objetos a e b, são iguais, a.equals(b) retorna verdadeiro, então os inteiros produzidos por a e b devem ser os mesmos, ou seja a.hashCode() == b.hashCode()

O inverso não é necessariamente verdadeiro, dois objetos que produzirem o mesmo hashCode podem ser diferentes

Diante disso a utilização do hashCode é principalmente para excluir igualdade, ou seja, ele serve como uma peneira, e é largamente utilizado por Collection em buscas como contains, remove, removeAll, retainAll entre outras coisas. A ideia é se os hashCode são diferentes então não é preciso testar a igualdade, pois já se garante que os objetos não serão iguais, poupando processamento no momento da busca, pois hashCode usa um calculo com int, que consome pouco processo, geralmente bem menos que o equals.

Existem varias estrategias para calculo do hashCode, desde a mais simples, onde vc praticamente exclui a funcionalidade do hashCode, deixando seu valor constante para qualquer objeto.

@Override
public int hashCode() {
    return 0;
}

Este método acima, funciona e respeita as regras de contrato de hashCode, porem seu programa poderá perder em velocidade. É extremamente desaconselhavel o uso de hashCode constante para qualquer objeto, pois várias funcionalidade que otimizam processos de busca não terão serventia com um hashCode mau projetado.

A melhor estratégia para hashCode é olhar para equals, e verificar como a igualdade é exegida, e assim montar um hashCode, concetenando os hashCode dos objetos que fazem a igualdade e designando um peso para as propriedades.

Por exemplo, para nossa classe Pessoa uma boa estrategia de hashCode seria

@Override
public int hashCode() {
    int hash = 7;
    hash = 23 * hash + (getCpf() != null ? getCpf().hashCode() : 0);
    return hash;
}

O número 7 contido nesse hashCode é apenas um número randomico para startar o hashCode, e diferenciar de outros objetos, por exemplo, um objeto empresa poderia iniciar por 3. o número 23 é outro número randomico, usado para quando há varias propriedades e escalar o hashCode entre as varias propriedade que definem um objeto igual.

Como no exemplo acima usamos o hashCode da string cpf, e como String tem seu hashCode bem implementando, podemos assim garantir que sempre que os CPF forem iguais os hashCode serão iguais.

Conclusão:

A igualdade entre objetos é uma parte fundamental da programação, e é uma das necessidades basica de logica, saber se dois objetos são iguais.

A implementação destes dois métodos é importante, e deve ser implementado em todas as classes instanciáveis do projeto, de forma a prover mecanismos corretos de comparação de igualdade (equals), assim como uma forma de otimizar os processos de busca (hashCode).

Muitos programadores só começam a entender a real necessidade da correta implementação destes dois métodos ao utilizar mais largamente a Java Collection Framework do pacote java.util, pois varios de seus métodos como contains, removeAll, remove, ratainAll ... falham quando equals não esta corretamente implementado, e perdem perfomance ou falham quando hashCode não esta otimizado ou corretamente implementando.

CollectionUtils e Filter Manipulando e criando buscas.

2009-04-02T10:40:00.006-03:00

A algum tempo atrás eu andava com uma dúvida de como realizar buscas genéricas em uma Collection tipada, ate que um colega Sérgio Taborda me sugeriu o uso de uma interface muito simples.

A ideia é muito simples cria-se uma interface chamada Filter<T> que é um contrato, que relata como deve ser o objeto que queremos encontrar, e então cria-se rotinas simples baseando neste contrato (a interface) para buscas.

interface Filter<T>

/**
 * Filtro de objeto, que testa se um obejto candidato T confere com o filtro.
 * @author Tomaz Lavieri
 * @param <T> o tipo de objetos que o filtro testa.
 * @see CollectionUtils
 */
public interface Filter<T> {
    /**
     * Verifica se o objeto candidato passa pelo filtro.
     * @param candidate Objeto candidato.
     * @return  <tt>true</tt> - caso o candidato passe no filtro.
     *          <br><tt>false</tt> - caso o candidato não pesse pelo filtro.
     */
    public boolean match(T candidate);
}

É com essa ideia do filtro, que se cria um critério para buscas em coleções, por exemplos, vamo supor que agente tem uma classe chamada Pessoa e que queremos buscar todas as pessoas que contenham o nome "João" e que a idade seja maior ou igual a 18 anos.

Filter<Pessoa> joaoMaioresDe18 = new Filter<Pessoa>() {
    public boolean match(Pessoa candidate) {
        boolean nomeOk = candidate.getNome() != null ? 
            candidate.getNome().toLowerCase().contains("joão") :
            false;
 
        return nomeOk && candidate.getIdade() >= 18;
    }
};

Agora temos um critério de busca que foi guardado na variável joaoMaioresDe18 e podemos checar facilmente se qualquer pessoa passa pelo criterio utilizando joaoMaioresDe18.match(pessoa); este retorna true caso a pessoa seja um joão maior de 18 anos.

Agora podemos criar uma rotina para buscar em uma lista, todas as pessoas que pertençam ao criterio informado, ficando assim:

List<Pessoa> pessoas = getAllPessoas(); //abstraindo como essa lista é obtida.
List<Pessoa> resultado = new ArrayList<Pessoa>(0); //guarda o resultado
for (Pessoa pessoa : pessoas) //realizando a busca
    if (joaoMaioresDe18.match(pessoa))
        resultado.add(pessoa);

Após isto, temos em resultado, todas as pessoas que contém o nome "joão" e que são maiores de idade.

Ficou bom, mais o processo pode ser automatizado e tornar-se ainda melhor, para isso é criado uma classe utilitária chamada CollectionUtils onde podemos guardar rotinas como:

Buscar todos os resultados que coincidem com o filtro - findAllMatch
Buscar todos os resultados que não coincidem com o filtro - findAllNotMatch
Buscar o primeiro resultado que coincidir com o filtro - findFirstMatch
Buscar o primeiro resultado que não coincir com o filtro - findFirstNotMatch
Reter na lista total apenas os objetos que coincidirem com o filtro - retainAll
Remover da lista total todos os objetos que coincidirem com o filtro - removeAll
Adciona a uma segunda lista todos os itens da primeira lista que coincidirem com o filtro - addAllMatch
Adciona a uma segunda lista todos os itens da primeira lista que não coincidirem com o filtro - addAllNotMatch

Colocarei aqui apenas um trecho de CollectionUtils e o link para o código completo segue aqui http://pastebin.com/f9d80cb7

class CollectionUtils

import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;
import java.util.List;
 
/**
 * Classe utilitária para manipular coleções
 * @author Tomaz Lavieri
 */
public class CollectionUtils {
    /**
     * Não é possivel instaciar CollectionUtils.
     */
    private CollectionUtils(){}
 
    /**
     * Busca todos os objetos <b>T</b> na lista de <tt>candidates</tt> que
     * conferem com o <tt>filter</tt>.
     * <BR>
     * <BR>Tem o resultado inverso a {@link #findAllNotMatch(Collection, Filter)}
     * @param   <T> o tipo de objeto a ser buscado.
     * @param   candidates a coleção de condidatos aonde deseja-se realizar a
     *          busca.
     * @param   filter o filtro que será usado para <b><u>aceitar</u></b> um
     *          candidato no resultado da busca.
     * @return  todos os itens que passaram pelo filtro.
     * @see #findAllNotMatch(Collection, Filter)
     */
    public static <T> List<T> findAllMatch(Collection<? extends T> candidates,
            Filter<T> filter) {
        List<T> matchs = new ArrayList<T>(0);
        addAllMatch(candidates, filter, matchs);
        return matchs;
    }
 
    /**
     * Adciona a coleção <tt>recipient</tt> todos os objetos <tt>T</tt> da lista
     * de <tt>candidates</tt> que coincidirem com o <tt>filter</tt>.
     * <BR>
     * <BR>Adciona o inverso dos itens de <tt>candidates</tt> que
     * {@link #addAllNotMatch(Collection, Filter, Collection)} adcionaria.
     * @param   <T> o tipo de objeto a ser adcionado.
     * @param   candidates a coleção de candidatos a serem adcionados ao
     *          <tt>recipient</tt>.
     * @param   filter o filtro que será usado para <b><u>aceitar</u></b> um
     *          candidato a ser adcionado ao <tt>recipient</tt>.
     * @param   recipient coleção onde os objetos serão adicionados.
     * @see #addAllNotMatch(Collection, Filter, Collection)
     */
    public static <T> void addAllMatch(Collection<? extends T> candidates,
            Filter<T> filter, Collection recipient) {
        for (T object : candidates)
            if (filter.match(object))
                recipient.add(object);
    }
    
//... restante da classe segue no link indicado
 
}

Agora com essas duas classes, basta criar um filtro, e mandar junto com a coleção, para CollectionUtils e receber os resultados.

Desta forma espera-se aumentar a produtividade, e facilitar a manipulação de coleções.

Filter.java
CollectionUtils.java