Consider renaming MergedAnnotation.getParent()

[sbrannen]

Consider renaming MergedAnnotation.getParent() in order to avoid confusion regarding the top-down hierarchical nature of annotation declarations and reversed parent/child relationships.

See discussions in #22818.

[philwebb]

If I think about that specific @transactional in the context of a @RepositoryTests declaration then it feels right to say this specific @transactional has a parent @MyTransactional which has a parent @RepositoryTests (the root).

...

I disagree with that. We literally have a top-down inheritance hierarchy from @transactional down to @RepositoryTests, and that is reflected in the attribute merging and overriding algorithm: children inherit and potentially override attributes from their ancestors, analogous to class hierarchies.

I guess it depends on what you consider the starting point. Given the following:

@interface Transactional

@Transactional
@interface MyTransactional

@MyTransactional
@ContextConfiguration
@RepositoryTests

@Transactional
@Service
@interface TransactionalService 

A logical top-down view would look like this:

                                      Transactional      
                                        ^      ^          
                                        |      |          
   ContextConfiguration    MyTransactional    TransactionalService
                  ^          ^
                  |          |
                RepositoryTests

You could say that @Transactional has two children (@MyTransactional and @TransactionalService) and @MyTransactional has one child (@RepositoryTests). If you start by thinking about @Transaction this makes sense. The problem I have with that description is it's thinking about @Transactional as the main thing, when in reality it's the declared annotations that drive the view of @Transactional. The @Transactional obtained via @RepositoryTests may have entirely different alases than the one obtained via @TransactionalService. You always need to consider @Transactional in the context of the way it was obtained.

That's why I've found it easier flip things on their head. If you imaging picking that tree up by the declared @RepositoryTests annotation it would look like this:

                RepositoryTests
                    |        |         
                    v        v         
   ContextConfiguration    MyTransactional  
                             ^
                             |
                        Transactional      

If you picked it up by the @TransactionalService it would look like this:

  TransactionalService
          |
          v
      Transactional

I then find in this scenario it's easier to think of the parent/child relationships as switched. The context of the annotation is especially important. If you image this class:

@RepositoryTests
@TransactionalService
static class MyClass {
	
}

We've actually got two different @Transaction annotations. We've got @TransactionalService/@Transactional and @RepositoryTests/@MyTransactional/@Transactional. I don't know why, but I find it quite confusing to think that a method named getChild() would only return one item, and that item would be different depending on the context. For some reason I find getParent() a much more natural way to think about it.

I do remember considering some other method names when I was originally designing the new API. I was thinking getSource() at one point, but I decided to keep that for returning the Class or Method that declared the annotation. The other name I though about was getOwner() but in the end I found getParent() to feel more natural.

[sbrannen]

Thanks for making the changes in e386e53! 👍