What does the term Plain Old Java Object(POJO) exactly mean?

Question

What does the term Plain Old Java Object(POJO) mean ? I couldn't find anything explanatory enough.

POJO's Wikipedia page says that POJO is an ordinary Java Object and not a special object. Now, what makes or what doesn't make and object special in Java ?

The above page also says that a POJO should not have to Extend prespecified classes, Implement prespecified Interfaces or Contain prespecified Annotations. Does that also mean that POJOs are not allowed to implement interfaces like Serializable, Comparable or classes like Applets or any other user-written Class/Interfaces?

Also, does the above policy(no extending, no implementing) means that we are not allowed to use any external libraries, frameworks?

Where exactly are POJOs used?

Answer 1

Plain Old Java Object :)

Well, you make it sound like those are all terrible restrictions.

In the usual context where POJO is/are used, it's more like a benefit:

It means that whatever library/API you're working with is perfectly willing to work with Java objects that haven't been doctored or manhandled in any way, i.e. you don't have to do anything special to get them to work.

For example, the XStream XML processor will (I think) happily serialize Java classes that don't implement the Serializable interface. That's a plus! Many products that work with data objects used to force you to implement SomeProprietaryDataObject or even extend an AbstractProprietaryDataObject class. Many libraries will expect bean behavior, i.e. getters and setters.

Usually, whatever works with POJOs will also work with not-so-PO-JO's. So XStream will of course also serialize Serializable classes.

Answer 2

POJO is a Plain Old Java Object - as compared to something needing Enterprise Edition's (J2EE) stuff (beans etc...).

POJO is not really a hard-and-fast definition, and more of a hand-wavy way of describing "normal" non-enterprise Java Objects. Whether using an external library or framework makes an object POJO or not is kind of in the eye of the beholder, largely depending on WHAT library/framework, although I'd venture to guess that a framework would make something less of a POJO

Answer 3

Usage of the term implies what it's supposed to tell you. If, for example, a dependency injection framework tells you that you can inject a POJO into any other POJO they want to say that you do not have to do anything special: there is no need to obey any contracts with your object, implement any interfaces or extend special classes. You can just use whatever you've already got.

UPDATE To give another example: while Hibernate can map any POJO (any object you created) to SQL tables, in Core Data (Objective C on the iPhone) your objects have to extend NSManagedObject in order for the system to be able to persist them to a database. In that sense, Core Data cannot work with any POJO (or rather POOCO=PlainOldObjectiveCObject) while Hibernate can. (I might not by 100% correct re Core Data since I just started picking it up. Any hints / corrections are welcome :-) ).

Answer 4

According to Martin Fowler, he and some others came up with it as a way to describe something which was a standard class as opposed to an EJB etc.

Answer 5

The whole point of a POJO is simplicity and you appear to be assuming its something more complicated than it appears.

If a library supports a POJO, it implies an object of any class is acceptible. It doesn't mean the POJO cannot have annotations/interface or that they won't be used if they are there, but it is not a requirement.

IMHO The wiki-page is fairly clear. It doesn't say a POJO cannot have annotations/interfaces.