On 14/09/2011 01:10, Greg Dritschler wrote:
These questions have come up before, and in the past we've looked at the Common
Annotations for the
Java Platform specification (aka JSR 250) for guidance. The rules being
proposed here appear to be
in opposition to one of those guidelines:
(page 2-6)
4. 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.
This guideline makes a lot of sense to me and in my opinion it would be a
mistake to do something
different.
Can we go back to the original problem? What code is deciding that an
unannotated field in a
superclass is a property? I don't see the code that would do that.
Greg
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.
