Currently it is unclear from the documentation if having a @DependsOn relationship between two beans implies that the dependant bean will be destroyed after the dependency:
If you want to influence the startup creation order of certain beans, consider declaring some of them as @Lazy(for creation on first access instead of on startup) or as @DependsOn certain other beans (making sure that specific other beans are created before the current bean, beyond what the latter’s direct dependencies imply).
Beans on which the current bean depends. Any beans specified are guaranteed to be created by the container before this bean. Used infrequently in cases where a bean does not explicitly depend on another through properties or constructor arguments, but rather depends on the side effects of another bean's initialization.
However, the semantics of destroy are clear in the XML case:
The depends-on attribute in the bean definition can specify both an initialization-time dependency and, in the case of singleton beans only, a corresponding destroy-time dependency. Dependent beans that define a depends-on relationship with a given bean are destroyed first, prior to the given bean itself being destroyed. Thus, depends-on can also control shutdown order.