Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question for Chris Richardson : what do you call POJOs ?

 
Celinio Fernandes
Ranch Hand
Posts: 549
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A question for Chris Richardson whom I assume he perfectly knows the definition of a POJO :
there seems to be 2 definitions for POJO, it's either a plain old Java object, that is a normal Java class, or a Javabean class, with getters and setters.

So, which one is it ?
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dont forget that a Java bean is also a POJO.
 
Kamal Mettananda
Ranch Hand
Posts: 51
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But what I have heard is,
POJO: Pure Java Object.

Which is the correct one?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
POJO == Plain Old Java Object
[ January 24, 2006: Message edited by: Paul Sturrock ]
 
Hemant Agarwal
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is Plain Old Java Object???
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Hemant Agarwal:
What is Plain Old Java Object???


http://www.martinfowler.com/bliki/POJO.html
 
Chris Richardson
author
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

The most definition of a Plain Old Java Object (POJO) is an object that does not implement any special interfaces (ie. interfaces defined by an infrastructure framework such as EJB).

I think its useful to extend that definition to prohibit POJOs from directly calling infrastructure framework APIs. Using this extended definition results in code that is decoupled from the infrastructure frameworks.

This has several benefits
* Its easier and faster to test - no waiting for the code to deploy or dependency on things that slow down testing such as a database
* Developers who have domain expertise but not infrastructure expertise can work on the code
* Your code is not impacted by rapidly evolving Java infrastructure frameworks some of which change incompatibly from one version to the next.

One interesting issue is whether POJOs with annotations are still POJOs. There is a case to be made that infrastructure framework-specific annotations introduces undesirable dependencies in the same way that implementing framework-specific interfaces does. (see http://www.aspectprogrammer.org/blogs/adrian/2004/08/when_is_a_pojo.html)

Chris
 
Balan Raj
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When Java started off wasn't it all POJO's which you built your own classes. Then came the hoo-haa's about new frameworks and models which were supposed to "do everything" for the application developer. I am sure that these frameworks had its own advantages. People and corporations took these frameworks/ APIs and built a lot of applications/ services.

Now aren't we going multiple steps backwards in proclaiming POJO as the next "in" thing ?

To me, if I had written an application some 6 years ago and did NOT bother to follow the herd to convert my applications to be J2EE compliant, I am now in the world of POJOs !!! Correct me if I am wrong !

I believe after building all these complex blocks, we are claiming that "Oh! all these complexities are too much.. lets get back to the basics" Maybe there are benefits but isnt it turning the clock backwards ?
 
Chris Richardson
author
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Balan,

One way to look at the evolution of java frameworks:

0. No frameworks.

Your application code consists of a mixture busines logic + infrastructure logic (transactions, persistence etc) that you had to write yourself.

1. Invasive infrastructure frameworks such EJB 2.

The frameworks took care of the infrastructure issues (so you didn't have to write it yourself) but either (a) your classes had to implement special interfaces or (b) call framework APIs

2. Non-invasive frameworks/POJO-style programming

The frameworks still take care of infrastructure issues BUT very little of your code is coupled to those frameworks. For example, Spring provides transparent transaction management, Hibernate provides transparent persistence and only the small amount of DAO code has to call Hibernate APIs

Given all of the issues/benefits discussed previously I would claim that this is big step forward.

Chris
 
Eric Gero
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure I understand what you are saying. EJB2 is an "Invasive Framework" because you have to implement special interfaces or call framework API's? I don't disagree with that statement, but not sure I have ever thought about it that way.

Thanks,
Eric
 
Eric Gero
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also meant to ask... Do you think the trend (for Sun) is to start moving away from invasive frameworks?

Thanks,
Eric
 
Sudd Ghosh
Ranch Hand
Posts: 191
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for explaining about "Non-invasive frameworks/POJO-style programming". Always thought POJO is mere java without frameworks.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic