Pretty much. It is normally used with reference to a persistence technology such as Hibernate. Here the "POJO" differenciates from the non-POJO alternative: an Entity Bean. Basically an Entity Bean relies on the environment it is deployed in to work, so gets behaviour and properties from the container it is deployed in. This isn't true of a POJO, which contains all its own properties and provided methods to define its own behaviour.
Pretty much any class is a POJO, but it depends a bit on the context of the conversation.
For example if you are talking about persistence, saying that the persistence layer will work with POJO's means that you're not forced to subclass something from that framework in order to use the framework. You may have to follow some general coding practices (such as basic Java Bean standard getters/setters and maybe a no args constructor), but no requirments in terms of special subclassing or interface implementation.
The framework in question will usually use some or all of reflection, config files, bytecode manipulation, dynamic code generation/subclassing, and there are probably other techniques I've left off.
Joined: Jan 24, 2001
I see, a POJO is better related to JavaBean where it's a self contained class, a component perhaps (server side)? [ June 29, 2005: Message edited by: Alex Kravets ]
Many developers will write POJOs for business logic, to be invoked by servlets, EJBs, Struts Actions, etc. In such a case, the POJO must be declared public and must not be tied to any client (in the interest of reusability).