Mike, Yes, I think you are right. The introspector shouldn't visit the superclasses. Instead, it should just visit the implementation class. I would think though that this should include the inherited members (i.e. members not hidden by redeclaration in the implementation class). I'd really have to ponder JSR 250 some more though.
On Fri, Sep 16, 2011 at 6:17 AM, Mike Edwards < mike.edwards.inglen...@gmail.com> wrote: > >> Greg, > > Regarding JSR250 and annotations, you are totally correct. > > However, the question for SCA and the specifications is not about the > inheritance of annotations or the inheritance of methods, fields etc. The > specifications are making statements about what gets introspected - ie the > algorithm that is used to introspect some class to determine the component > type. > > The decision made by the spec folks was that it is important to enable the > subclass to be in control - and to do this, it is necessary to limit the > introspection of the class to the artifacts that it declares itself - and > not to introspect aspects of the parent class. > > The simplest example concerns the @Service annotation. If the superclass > has an @Service annotation and if that annotation was always scanned by the > introspection process, then the implication is that the subclass could never > "turn off" the @Service annotation. If the sublcass is to be in control, > then the introspection algorithm must not be able to examine the superclass > annotations. This is then extended to all the aspects of the introspection > algorithm. > > In some ways, this is a case of we're damned if we do and we're damned if > we don't. Either way we construct the introspection algorithm, there are > consequences for the developer - more work, more things to do. We've chosen > one approach - at least its consistent even if for some developers it means > more effort. I'm open to hearing that we've made the wrong choice, but it > is fair for me to ask for some convincing examples. > > > Yours, Mike. >
