Plain Old Java Object

POJO = "Plain Old Java Object". Term coined by MartinFowler, RebeccaParsons?, and JoshMacKenzie to denote a normal Java object that is not a JavaBean, an EntityBean, a SessionBean, etc., and does not serve any other special role or implement any special interfaces of any of the Java frameworks (EJB, JDBC, DAO, JDO, etc...).

Any Java object can run within an EJB container, but many people don't know that or forget it. Fowler et al invented the acronym POJO so that such objects would have a "fancy name", thereby convincing people that they were worthy of use.

POJOs are useful for creating a DomainModel. In contrast, the various types of beans and other special Java objects often have constraints that make it difficult to use them directly to model a domain.

I see a tendency of people fudging that definition of POJO because their ObjectRelationalMapping products obviously do not support POJO persistence, as they would like to announce. The typical case is referring to the JSR-220 (EJB3, JDO2) as "POJO persistence", when the EJB 3.0 early draft makes it clear that it is only a "Simplification of the enterprise bean types. Enterprise beans are simplified to more closely resemble plain Java objects ("POJOs") or JavaBeans." -- KlausWuestefeld

EJB3 is much, much better than previous versions. The only downside is the "DependencyInjection" mechanism that has completely misunderstood DependencyInjection and is therefore not helpful for breaking dependencies.

For real POJO persistancy have a look at PersistedObjectTree unlike KlausWuestefeld's Prevayler it lets you use any type of data structure. -- Bjorn Blomqvist

It's my opinion that the POJO concept and XDoclet are the nails in the coffin of the EJBs. The solutions to use EJBs (at least until version 2.1.) was to autogenerate garbage with code buried in comments (XDoclet) and hide this mess (POJO). I hope that EJB 3.0 is better than that, but I'm afraid I will not touch it with a ten foot pole. -- AurelianoCalvo