I don't remember where I've read that a JavaBean is a POJO which is managed by a dependency injection container. Does this always hold true? Or there is some other context in which JavaBean stands for something else?
EDIT:
This answer doesn't mention a DI container at all. So being managed by DI container isn't a required condition for a Java class to be a bean?
The JavaBeans standard predated DI frameworks, originally a prevalent use case was supporting drag-and-drop components (like those in Delphi or VB, which had component palettes of reusable widgets that could be dragged onto a form and wired together), with support for things like PropertyEditors and property sheets. Visual programming environments were huge back then, there was a market for third-party components, and Sun probably wanted something similar for Java.
Once people started conceiving of DI frameworks they needed a predictable way to set dependencies on their managed objects, so they appropriated the existing standard. From Rod Johnson's Expert One-on-one J2EE Design and Development:
If we make all application components JavaBeans, we maximize our ability to separate configuration data from application code. We also ensure that application components can be configured in a consistent way, wherever configuration data is held.
The term POJO was coined in 2000, with the idea of describing code that did not have explicit dependencies on a framework:
Ideally speaking, a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification
where the poster child for how not to do it was EJB prior to version 3, with invasive dependencies on framework classes that inhibited out-of-container testing.
DI frameworks were interested in providing functionality in a transparent and noninvasive way, JavaBeans provided a common standard that POJOs could use in order to expose their configuration, so they were a good match.