pessoal,
explica-me por favor para que serve annotations. Nao entendi ainda. 
Imagine que toda classe ou membro tem modificadores. Assim, uma classe pode ser definida como public, private, abstract, final e por ai vai. As Annotations são uma forma de você extender essas caracteristicas de acordo com a sua necessidade.
Quando você sobrescreve um metodo de uma classe, o toString() por exemplo, você pode colocar uma annotation @Override de que esse método está sendo sobrescrito. Assim, se o desenvolvedor da sua superclasse alterar a assinatura do meu médodo, o java gerará um erro de compilação indicando que um método com aquela assinatura não existe na superclasse.
Outras utilidades são a eliminação de XMLs para configuração, como ocorreu no EJB3 e no Hibernate Annotations.
Para saber mais: http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html
Annotations são uma espécie de Java doc para outras aplicações lerem (e não necessariamente seres humanos).
Uma dessas ferramentas é o compilador, como o colega explicou. Quando você põe @Override em cima de um método, o compilador consegue ler isso e dar avisos aos desenvolvedores das subclasses.
Veja o JUnit. Os desenvolvedores do JUnit precisavam saber quais métodos em uma classe eram de testes, quais eram de setup e quais eram de finalização. Para isso, criaram 3 anotações:
@Setup
@TearDown
@Test
Agora, o JUnit pode ler uma classe como esta
[code]public class UmaClasse {
@Test
public void displayCorreto {
//Teste do display aqui
}
@SetUp
public void configuraAmbiente {
//Setup da classe
}
}[/code]
E saber que os métodos displayCorreto e configuraAmbiente são os métodos de teste e setup, respectivamente.
Da mesma forma, o Hibernate definiu anotations para que você possa dizer a ele quais são os atributos que serão persistidos, a qual tabela uma classe pertence, etc. Todas essas são informações sobre a classe que o hibernate precisa saber, quando está analisando o objeto através da reflexão.
O legal dos annotations é que, do contrário do javadoc, essa informação não se perde na compilação. Outra coisa bacana é que você pode criar suas próprias anotações.
Para analisar essa informação utiliza-se reflexão. Até que você esteja familiarizado com reflexão, pode ser que não consiga ver muita utilidadade nelas.
Elas são uma “dica” que algum programa (por exemplo, o compilador, o servidor de aplicações, um framework etc.) pode usar para modificar o comportamento de alguma classe sua. Em vez de usar configuração separada de seu código (em arquivos XML que podem ficar fora de sincronia com seu código), pode-se fazer configuração no próprio código.
Exemplo 1 - EJB 3
No caso do EJB 3, o servidor de aplicações carrega as suas classes, e verifica que anotações estão associadas a elas. Dessa forma, ele pode criar novas classes a partir das suas, que efetuam o mesmo trabalho que originalmente você teria de codificar no EJB 2 ou anterior.
Exemplo 2 - JPA e Hibernate 3
Neste caso, a biblioteca carrega as suas classes, e efetua a configuração necessária para que sejam mapeadas para as tabelas do banco de dados.
Exemplo 3 - @Deprecated, @Override e @SupressWarnings
Essas anotações são entendidas diretamente pelo compilador e indicam para ele que o método está obsoleto (deprecated), que ele deve sobrepor um método da classe-base (override) ou que ele não deve acusar um determinado “warning” porque “você sabe o que está fazendo” (suppress warnings) Assim não é necessário criar novas palavras-chave na linguagem, e tais anotações podem ser ignoradas pelo compilador se ele não as entender.
[quote=PePeLeGaL]pessoal,
explica-me por favor para que serve annotations. Nao entendi ainda. [/quote]
Uma forma muito, muito ruim de se adicionar metadados necessários a determinada aplicaçõa/framework ao bytecode de uma classe…
Por que você considera “muito, muito ruim”?
[quote=psevestre][quote=PePeLeGaL]pessoal,
explica-me por favor para que serve annotations. Nao entendi ainda. [/quote]
Uma forma muito, muito ruim de se adicionar metadados necessários a determinada aplicaçõa/framework ao bytecode de uma classe…
[/quote]
Eu fico imaginando se tudo que fosse novo fosse ruim, só por que é novo. Fique você com o IBM WebSphere 4.1 ou o Sun iPlanet 6.0 e veja se você prefere essas versões antigas 
E só pelo fato de ser novo (e annotations não são o que eu chamaria de novo) tb. não significa ser melhor - vide o Vista.
Acho que já expressei minha opinião sobre annotations em algum outro post, mas vamos lá…
-
Não sou contra se ter bytecode “enriquecido” com metadados, e, muito menos, em se ter a API para recuperar estes metadados - este sim um avanço.
-
Minha aversão é quanto à forma escolhida para se mesclar os metadados com o fonte - as arrobas espalhadas por todo o lado. O ideal é que isto fosse mascarado pela IDE, algo que elas já fazem com os xdoclets da vida.
-
IMO, os JSRs deviam é ter definido um schema XML para código fonte (aliás, é bem provavel que exista algum…), diretamente compilável pelo javac. Como o desenvolvimento hoje em dia é feito 99% do tempo usando-se IDEs, o formato de armazenamento é irrelevante (eu só não escolheria um formato binário por trauma do VB3…).
Uma IDE moderna pode muito bem ler o fonte XML e permitir sua edição na forma tradicional. Usando-se “profiles” adequados, o desenvolvedor ativaria quais anotações estariam disponíveis, e sua edição poderia ser feita de forma bem mais amigável. Ex: rclick em propriedade -> metadados -> hibernate -> Abre form para edição de metadados de ORM.
Se vc. pensar, já que permitiram metadados no nível de método e atributos de classe, pq não o fizeram no nível de sentença ? Eu poderia dar “dicas” para a JVM que permitiriam (ou não) paralelizar determinados grupos de sentenças, aproveitando-se dos múltiplos pipelines de instrução dos processadores atuais. Esta foi só a primeira idéia que me veio à cabeça.
Não posso opinar relevantemente sobre as Annotations uma vez que meu estudo sobre tais é básico.
Só quero ressaltar uma opinião já expressa nesse tópico concordando com a idéia de que encher os bytecodes com metadados é uma prática ruim ao meu ver.
Acho as Annotations úteis, mas poluir o código final com esse tipo de coisa é algo do qual não sou muito agradado.
Relembrando: opiniões são opiniões.
Post duplicado, por favor, apaguem.
P.S.:
public final String[] ask {
"Só aqui o GUJ sai fora do ar o tempo todo?"
"Sim"
"Não"
};Por outro lado, psilvestre, se a IDE controlasse isso em algum arquivo externo, você passaria a ter 2 arquivos para o fonte de uma só classe, ao invés de um só. Você também seria obrigado a ter uma ide caso quisesse alterar uma anotação (mesmo em campo, caso você quisesse recompilar rapidamente um arquivo para fazer um teste). Eu também não gosto dessa solução.
Também não acho que xml não seja a solução do problema. Meta dados com xml era o que o hibernate já fazia e a solução com o anotation direto ficou muito mais elegante.
Mas, eu concordo com você no seguinte: Arrobas por todo lado no código realmente não são uma coisa legal. Na verdade, eu não estava exatamente discordando de você. Só estava ressaltando que a solução que você apontou também tem pontos ruins.
Qual é a pior delas? Bom, não sei. Por hora é ir usando a que temos por aqui. 
[quote=ViniGodoy]Por outro lado, psilvestre, se a IDE controlasse isso em algum arquivo externo, você passaria a ter 2 arquivos para o fonte de uma só classe, ao invés de um só.
[/quote]
Quem falou em arquivo externo ? A idéia é colocar tudo no mesmo arquivo e, para isto, joga-se fora a representação “texto puro” do fonte e adota-se uma representação XML. As IDEs são perfeitamente capazes de ler o arquivo e mostrá-lo de forma “normal”. Pense no XMI, como um exemplo próximo.
Por isto é que não sugeri um formato binário, embora um xml (g)zipado provavelmente seria uma solução igualmente aceitável.
Particularmente, prefiro o XML, especialmente pelo fato de utilizar ferramentas que o geram de forma automática junto com as classes do domínio. Ou seja, para mim é como se não existissem - e fico sem as arrobas 