• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Question for Chris: are POJOs the poor relations of Java?

Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I make extensive use of POJOs in my designs, I like them, they seem to like me and they are comfortable, reliable and ask for very little in return...

However, I cannot shake the feeling that I'm using a 'poor relation' as opposed to use something snazzier (like EJBs) and sexier: certainly the "plain" and "old" in the name don't help, but, in your view, is my feeling right and I should move on my (Java)life on to something "newer" or are POJOs still very much as useful as I seem to think?

Thanks and looking forward to hearing from you.
Marco Massenzio
Managing Director
Infinite Bandwidth ltd
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

As you might expect I really like POJOs.

This is once of those instances where simple or plain objects are much more powerful than not-so-simple EJB 1/2. For example, here is some "simple" Java code:

class Person { String name; List<Person> dependents; ...}
class Employee extends Person { Person Manager; ...}

(slightly contrived example that but...)
Some things to note.

1 I can test this code without deploying it in an application server or without needing a database. The edit-compile-debug cycle is fast.

2 A developer who familiar with the problem domain but is not an EJB (or other infrastructure framework) can work on this code.

3 When its time to implement database access, its straightforward to do that with Hibernate, JDO or EJB3.

4 I can switch/upgrade infrastructure frameworks without rewriting my code

None of these things are true if I am using a snazier, not so plain technologies such as EJB2.
1. Code tends to be coupled to the application server and/or database, which slows down and complicates testing.

2. EJB2 beans are coupled to the framework requiring developers to have EJB expertise.

3. EJB2 could not easily persist even this simple domain model.

4. Upgrading your code from EJB version N to EJB version N+1 requires changing it.

Just a few reasons why I prefer the power of Plain Object Java Obejcts.

Marco Massenzio
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Chris

I sort of suspected that (especially the bit about the rapid development-debug cycle) but it's good to hear it from someone like you!

And when my army is complete, I will rule the world! But, for now, I'm going to be happy with this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic