Let me try quick answer:
It is Plain Old Java Object and the term POJO is used in context of business layer of enterprise apps. With
J2EE app server business objects are realized through EJBs, which are
not POJOs, but a bit more complicated:
- are defined through 4 or more source files (Home Interface, Object Interface, Bean Class, deployment descriptor)
- difficult to put into an inheritance hierarchie, association.
- difficult to
test, because depends on Container of AppServer, which needs to be started with any test (slow)
Some people say that the standardized services a AppServer provides (for transaction handling, security, remoting, caching, etc.) doesn't outweigh the costs of the more complex structure of EJBs brings with (in comparision with POJO).
So they have build own frameworks like spring, hibernate, etc. which tries to solve the typical problems of Enterprise Apps like object relational mapping, transactions, securtiy, localization of objects, etc. with the goal that the user (= application programmer) can use simple, easy to test Plain Old Java Objects. This POJOs shall not put extra restrictions/complexity/burden on inheritance, association, testability and - depending on context - performance, which EJB does.
There is lot of debate around pojo/ejb and one should read them with a lot of doubt. There is no simple truth and what framework/standard is best depends on a lot of specific factors (specifics of apps, type of organization, type of developers, etc.)
Axel
[ October 30, 2004: Message edited by: Axel Janssen ]