The use of Autowire for Spring was due to some mis-communication. Yale had suggested that the configuration file should be simpler when possible. However, our intent was to suggest that afterPropertiesSet() fill in required dependencies with an instance of the obvious default class implementation. Thus the Bean configuration would only need to specify the non-obvious dependencies. However, the objective of simpler configuration was extended to autowire, that is not specify a property when there is only one Bean of the appropriate type to satisfy the property. We finally realized that we all agreed that autowire was a bad practice.

I don't know if there is a Best Practices for JavaDoc in Spring, but it is obvious that there should be some differences between a Spring Bean and a POJO. The class level JavaDoc comment should explicitly reflect the Wiring requirements. What is required, what is optional, how this interacts with other beans, any life cycle considerations, etc.

A Plain Old Java Object is created by new and therefore must be constructed in is constructor. A Spring Bean can be "constructed" with an actual constructor, but stylistically is often constructed by a sequence of property setters ending in a afterPropertiesSet() which can then apply defaults or throw errors. This altered construction behavior becomes part of the class definition itself, because it defines what you have to do to get a usable instance of the type.

I would also suggest that if you really want to use Autowire in the config, that the expectations be declared in the class JavaDoc, and that the singleton/prototype be declared here. There is no better place for it, and this minimal amount of information should be in the program documentation somewhere and not just in some external configuration document.