Annotations

Annotation não é Java não, vc está bem enganado.

Tem como fazer um loop ou um if dentro de uma annotation?

Ninguém é contra annotation. Annotation tem seu uso. Só tem que tomar cuidado para não abusar dela, como foi feito com o XML.

Dá uma olhada na validação do Struts2: http://struts.apache.org/2.x/docs/validation-annotation.html

Quando a coisa chega nesse nível eu prefiro, e isso é a minha opinião pessoal, usar Java mesmo:

public class MyAction implements Validatable {
    
    public String execute() throws Exception {
        
        // your action stuff here...
        
    }
    
    public void prepareValidator(Validator val, String innerAction) {
        
            Rule required = RequiredFieldRule.getInstance();
        
            val.add("username", required, FIELD_REQUIRED_ERROR);
            val.add("username", StringRule.getInstance(6, 30), INVALID_USERNAME_LENGTH);
        
            val.add("age", required, FIELD_REQUIRED_ERROR);
            val.add("age", IntegerRule.getInstance(18, 50), INVALID_AGE);
        
            val.add("password", required, FIELD_REQUIRED_ERROR);
            val.add("password", StringRule.getInstance(4, 20), INVALID_PASSWORD_LENGTH);
            val.add("password", EqualRule.getInstance("password", "passconf"), PASSWORD_DOES_NOT_MATCH);
        
            val.add("passconf", required, FIELD_REQUIRED_ERROR);
            
    }
    
    private static final String FIELD_REQUIRED_ERROR = "Field required!";
    private static final String INVALID_USERNAME_LENGTH = "Username length invalid!";
    private static final String INVALID_AGE = "Invalid age!";
    private static final String INVALID_PASSWORD_LENGTH = "Invalide password length!";
    private static final String PASSWORD_DOES_NOT_MATCH = "Passwords do not match!";
}

Como qualquer coisa pertencente ao universo java, Annotations tem vantagens e desvantagens. Annotations são simples de implementar e muito melhor do que fazer uma tonelada de arquivos de configuração (não necessariamente em XML).

Mas, a principal desvantagem é que elas tem que ficar no código-fonte. Portanto para mudar uma vírgula que seja é preciso recompilar. Se o seu programa estiver distribuído em 10000 clientes, ter que recompilar e redistribuir tudo pode ser um pesadelo.

Outro problema das annotations é que, embora elas sejam um tipo de acoplamento relativamente fraco, elas ainda são um tipo de acoplamento. Sua classe depende da annotation para compilar. Se algo mudar na annotation, sua classe não compila mais. Embora isso normalmente não seja problema, frameworks que abusam de annotations tendem a te obrigar a entupir as suas classes com annotations, e no final o ganho em relação a implementar uma interface escabrosa do framework (como era antes das annotations) é pequeno.

Outro problema é que as annotations são imutáveis. Não é possível alterar seus valores em tempo de execução.

Mais outra desvantagem é que rastrear bugs no uso de annotations é muito mais difícil do que bugs no uso de interfaces, sobreposição de métodos ou herança. Porém tende a ser mais fácil do que rastrear bugs em arquivos XML.

Mas, colocando-se na balança, acredito que annotations são ferramentas excelentes, fáceis e leves, portanto foi um ponto positivo adicioná-las no java 5. Porém ainda assim tem suas desvantagens.

victorwss:

Como qualquer coisa pertencente ao universo java, Annotations tem vantagens e desvantagens. Annotations são simples de implementar e muito melhor do que fazer uma tonelada de arquivos de configuração (não necessariamente em XML).

Mas, a principal desvantagem é que elas tem que ficar no código-fonte. Portanto para mudar uma vírgula que seja é preciso recompilar. Se o seu programa estiver distribuído em 10000 clientes, ter que recompilar e redistribuir tudo pode ser um pesadelo.

Outro problema das annotations é que, embora elas sejam um tipo de acoplamento relativamente fraco, elas ainda são um tipo de acoplamento. Sua classe depende da annotation para compilar. Se algo mudar na annotation, sua classe não compila mais. Embora isso normalmente não seja problema, frameworks que abusam de annotations tendem a te obrigar a entupir as suas classes com annotations, e no final o ganho em relação a implementar uma interface escabrosa do framework (como era antes das annotations) é pequeno.

Outro problema é que as annotations são imutáveis. Não é possível alterar seus valores em tempo de execução.

Mais outra desvantagem é que rastrear bugs no uso de annotations é muito mais difícil do que bugs no uso de interfaces, sobreposição de métodos ou herança. Porém tende a ser mais fácil do que rastrear bugs em arquivos XML.

Mas, colocando-se na balança, acredito que annotations são ferramentas excelentes, fáceis e leves, portanto foi um ponto positivo adicioná-las no java 5. Porém ainda assim tem suas desvantagens.

Parece eu falando com outro apelido.

E vc encontrou outra desvantagem de annotations que eu não conhecia: a imutabilidade. Configuração programática não tem esse problema, né?

Eu prefiro configuração programática a annotations, mas isso é a minha opinião pessoal. Frameworks baseados em annotions (Seam, VRaptor, Stripes) são plenamente possíveis e práticos, mas como o Victor resumiu muito bem, annotations tem suas desvantagens!

Ok saoj, quando eu disse que Annotations é java quis dizer que Annotations agora fazem parte da API do java ou seja, vc não precisa nada além do JDK 5 para utilizar.

Vitor, entenda que não estou descordando de vc, apenas mostrando um outro ponto de vista sobre cada desvantagem.

Concordo!

Ou seria uma vantagem?? Refactor por exemplo…

Além disso se o cara não tiver um esquema de distribuição como o JWS ou um compartilhamento na rede ele que se mate… e as configurações em java citadas pelo Saoj caem no mesmo problema.

Entenda mudar uma annotation como mudar a especificação do seu XML vai ter que recompilar tudo do mesmo jeito…

Sim, e como na maioria dos frameworks que usam xml vc precisa reiniciar para recarregar o XML.

Não entendo que tipo de bugs podem existir em annotations bem elaboradas.

Annotations não vieram para substituir o XML. O que acontece é que o trabalho de configuração que era feito em XML, agora é feito em annotations. Porém annotations não substituem XML e por outro lado annotations fazem coisas que antes nem se sonhava em se fazer com XML.

O que eu estava me referindo, é um caso mais ou menos assim: Suponha que o framework escabroso versão java 1.4 utilize interfaces, sobreposição de métodos e herança para fazer o seu serviço (sem utilizar uma única linha de XML). Agora, imagine que na versão java 5 ele passe a usar annotations ao invés de interfaces, sobreposição de métodos e herança. Se o framework for um destes bloatware muito mais complexo do que deveria ser, ao invés de você ter que implementar 10 interfaces, herdar de alguma classe esotérica e ter que sobrepor 50 métodos, você fica com a herança livre, não tem que sobrepor e nem implementar método nenhum, mas em compensação tem que colocar 1000 annotations na sua classe. Enfim, o que eu quis ressaltar aqui é o conceito de POJO. Trocar interfaces, herança e sobreposição por annotations não desvincula a sua classe do framework. Aqui eu não quis dizer nada em relação a XML.

A diferença é que arquivos de configuração são configuráveis diretamente, no cliente mesmo se for o caso. Annotations exigem recompilação.

Acontece que com annotations, não basta você reiniciar. Você tem que recompilar.

Bug na annotation em si, muito difícil. Mas eu estava me referindo ao uso inadequado de uma annotation. Coisa que o compilador pega em pouquíssimos casos e bugs estes que se manifestam em tempo de execução quando um código sem bug (o processador das annotations) é executado. Isso é porque o bug não está no processador das annotations, e sim nos seus dados de entrada, que são obviamente as suas classes. As suas classes por vez possuem código executável perfeitamente válido, o problema está no mal uso da annotation.