Lu dans la doc d’un framework : « un CouteauDeTable est une classe Java standard (ou POJO) qui sert à couper viande ou légume. Il doit sous-classer AbstractCouteau, n’utiliser dans ses signatures que les types Lame et Manche, avoir un constructeur comme ceci et des attributs comme cela. Et son nom doit finir par CouteauImpl. » 
C’est-à-dire, tout SAUF un POJO 
!
Ce terme est de plus en plus utilisé comme synonyme de « classe Java », ce qui est une erreur. Alors, qu’est-ce qu’un POJO au juste ? Et bien, ma définition en serait : une classe Java sans contraintes particulières.
En fait, il n’y a pas de POJO sans framework. Un framework peut vous demander de sous-classer telle ou telle classe, respecter telle convention de nommage, limiter ci, imposer cela. A l’opposé (et un peu en réaction aux EJB), on parle de POJO quand le framework justement n’impose rien sur vos classes Java : vous développez old-school, classes et interfaces sont conçues librement.
Exemple de framework pas-POJO-du-tout :
« Sous-classez com.framework.AbstractPrintableObject, avec un constructeur public à un paramètre de type com.framework.PrintEnvironment. Ne définissez que des méthodes publiques non synchronisées qui lèvent comme exceptions des sous-classes de com.framework.PrintException. etc… etc… »
Le même, façon j’aime-les-POJO :
« Passez-lui un POJO, le framework d’impression essaiera de découvrir ses getters publics et de construire une représentation textuelle imprimable. »
Je précise que j’écris ça dans un souci d’illustration, loin de moi l’idée de suggérer une quelconque supériorité d’une approche tout-POJO par rapport au framework de grand-papa qui offre un lot de superclasses abstraites. Par exemple, je trouve l’approche « pur-POJOs (ah oui, plus plein d’annotations) » un peu hypocrite… 
. L’article propose l’explication que c’est dû à une grande auto-discipline de développeurs, très probablement motivée par l’exposition publique du code source à conjointement au nom de son contributeur.
