What does "POJO" mean?

[Luca Vent]

Hello everybody!

I have found in this forum many references to the term "POJO" (Plain Old Java Object): what does it mean exaclty? It is a simple java class or what?
What is it useful for?

Thanks a lot!

Luca

[Axel Janssen]

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 ]

[Luca Ventura]

Thank you a lot Axel for you explanations...but I have three questions on POJO again:

1)Who is that execeute a POJO? The Application Server?
2)How is it possible to call a POJO?
2)Can both POJO and EJB handle the same type of protocols (http, rmi-iiop, etc)?

Thanks a lot in advance,

Luca

[Eric Lemaitre]

Hi Luca !

Without any intention to burst your thurst of knowledge, you should abandon your quest for POJO signification for it has no longer any sensible meaning.

In fact "POJO" moto has appeared at front place on many Java debates only because it is a pretext for a real war about EJB-3.0 and JDO-2.0 standards, which should lead to ... new standard SDO-1.0 which will adopt a (small) common trunk and if possible best features of the former two, but this war has been raging for commercial issues only, no technical issues.

You can translate POJO as "totally defined in Java source code only", so you can estimate that introspection respects POJO definition, OK. But as soon as you want any extra interesting feature (AOP, jdoclets, javadoc assertions, EJB, JDO, ...) not present in standard Java code, you must add extra definitions somewhere so as to implement this extra functionnality, and then you simply CANNOT be pure POJO any longer, but is it really so important ?
With AOP you must add Java classes for pointcuts and use a special compiler which will manage your POJO classes to build new not POJO ones with added features, JDO or Hibernate will need an extra metadata file to define persistance and will anyway transform too your POJO classes to build new not POJO ones with added persistance management features, EJB will need at least ComponentInterface+Home+Model and XML-DD files, and so on.

Even if you consider defining these features in javadoc comments in the jdoclet way, lurking you into the thought you are POJO because you use only standard Java code and associated javadoc comments, this implies some kind of processing which will make resulting classes no longer POJO at all, but with the benefit of added features esay to define even from Java code itself.

So in conclusion, don't care, POJO is a pure commercial argument which in totally unfair way tries to claim "we can add extra features which have no impact on your Java code while our concurrents cannot", but this is always pure commercial bullshit. On technical point of view new not Java standard features need extra definitions somewhere, either in javadoc comments or extra files, and Java can deal easily with them, period.

Best regards.