Pegar as anotacoes da classe pai

Front-end
#1

Pessoal,

Tava aqui implementando um lance como annotations mas via reflection eu nao consigo le as annotations das classes pai e entao sou obrigado a replicar as annotations pelas classes filha. Tem como consertar isso?

Alberto

#2

Olá

Dê uma lida nas primeiras páginas da JSR 250 da página 12 até a 14 no capítulo 2.1 General Guidelines for Inheritance of Annotations.

Lá explica claramente como é o conceito de herança quando anotacões estão envolvidas e como fica a questão de herança das anotações. O texto diz:

[quote=JSR250, página 12]
Guidelines recommended for how annotations defined in the different specifications should interact with inheritance:

1.Class-level annotations only affect the class they annotate and their members, that is, its methods and fields. They never affect a member declared by a superclass, even if it is not hidden or overridden by the class in question.

  1. In addition to affecting the annotated class, class-level annotations may act as a shorthand for member-level annotations. If a member carries a specific member-level annotation, any annotations of the same type implied by a class-level annotation are ignored. In other words, explicit member-level annotations have priority over member-level annotations implied by a class-level annotation. For example, a @WebService annotation on a class implies that all the public method in the class that it is applied on are annotated with @WebMethod if there is no @WebMethod annotation on any of the methods. However if there is a @WebMethod annotation on any method then the @WebService does not imply the presence of @WebMethod on the other public methods in the class.

  2. The interfaces implemented by a class never contribute annotations to the class itself or any of its members.

  3. Members inherited from a superclass and which are not hidden or overridden maintain the annotations they had in the class that declared them, including member-level annotations implied by class-level ones.

  4. Member-level annotations on a hidden or overridden member are always ignored.[/quote]

[]s
Luca

#3

Valeu Luca,

Obrigado pela explicacao.

Alberto

#4

oi Luca

isso é apenas uma recomendacao, na verdade voce pode sim acessar as anotacoes da classe mae da Class clazz. basta voce pegar a super class da clazz e pegar as anotacoes! afinal, voce faz o que quiser via as anotacoes descobertas…

eu acho essas recomendacoes bem estranhas. imagine que Serializable fosse uma anotacao (alias, seria se existissem anotacoes no java1), uma classe filha de uma classe @Serializable nao deveria ser @Serializable?

sei que depende do caso, mas entao porque recomendar o contrario?

#5

É isso Paulo, eu pensei em fazer isso, mas ai caso exista uma hierarquia maior teria que fazer uma tipo uma busca recursiva ate chegar a primeira o velho problema da herança. Vou anotar classe por classe mesmo.

Alberto

#6

seria uma recursao ou for com no maximo 10 iterações… voce nao deveria se preocupar com tanta otimizacao assim!!

o ebj3 faz VARIAS dessas buscas.

#7

Olá

Paulo

Fiz questão de colocar a JSR para chamar a atenção sobre alguns casos que eventualmente podem acontecer.

A JSR 250 começa assim:

“A interação entre anotações e herança na linguagem Java é potencialemente uma fonte de complexidade para os desenvolvedores. Os desenvolvedores se basearão em algumas suposições implicitas ao imaginar como as anotações funcionam em conjunto com outras facilidades da linguagem. Ao mesmo tempo, a semântica das anotações são definidas em especificações individuais e por esta razão aparecem as potenciais inconsistências. Por exemplo, considere o seguinte caso:”

public class Base {    
    @TransactionAttribute(REQUIRES_NEW)    
    public void foo {....}
}

@Stateless
public class Derived extends Base {    
    @TransactionAttribute(NEVER)    
    public void foo {....}
}

“Para manter o conceito de substituição de métodos, muitos desenvolvedores assumirão que no método foo da classe Derived, a anotação TransactionAttribute em vigor é @TransactionAttribute(NEVER). Por outro lado, seria possível a especificação exigir que a anotação em vigor fosse a mais restritiva em toda a árvore de heranças, que neste exemplo seria @TransactionAttribute(REQUIRES_NEW). A motivação para esta semântica seria pelo fato de que o método foo da classe Derived poderia chamar super.foo() resultando na execução de código necessitando transação definida. Esta escolha por parte de quem escreveu a especificação pode contradizer a intuição do desenvolvedor.”

Pelos motivos acima, a JSR escreveu o guidelines, que como você bem disse, são apenas recomendações.

Eu fiz questão de colocar os guidelines aqui para chamar a atenção que nem sempre seguir os conceitos de heranças que estamos acostumados pode estar certo. E por este raciocínio vejo algum risco em interpretar as anotações puramente a partir de reflection. Seria preciso conhecer também a especificação para avaliar se há risco ou não.

[]s
Luca

#8

Se é assim… :smiley: la vou eu fazer esse lance

Alberto

#9