aspose file tools*
The moose likes Object Relational Mapping and the fly likes Why POJO was not used before Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Why POJO was not used before" Watch "Why POJO was not used before" New topic
Author

Why POJO was not used before

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Lot of people now talk about using POJO/POJI for writing business/domain objects. I am surprised that the EJB architects (I am sure that they have many years of experience)& other experts failed to think about POJO when they first designed the EJB but forced the developer to implement some interface(Entity,session etc).Lot of authors and other experts wrote articles saying good things about EJB.

I am interested to know what Chris has to say for this.
thanks


Groovy
Theodore Casser
Ranch Hand

Joined: Mar 14, 2001
Posts: 1902

Not that I'm the author or an expert, but my guess (based on conversations my coworkers and I have had on the topic around our office) is that it's just a matter of things simplifying over time. I'm sure they'd have thought of POJOs sooner if the language features we have now (annotations and the like) had existed. Just a matter of whatever is available at the time.

Just my thoughts.


Theodore Jonathan Casser
SCJP/SCSNI/SCBCD/SCWCD/SCDJWS/SCMAD/SCEA/MCTS/MCPD... and so many more letters than you can shake a stick at!
Roy Ben Ami
Ranch Hand

Joined: Jan 13, 2002
Posts: 732
I think that they are 2 different approaches (each one with its own benefits and disadvantages).

One relies heavily on implmenting interfaces and extending objects (the old EJB 2.1) and the other on Meta-Data and Inversion-Of-Control (the new EJB 3.0 spec).

I think that the POJO approach is a bit cumbersome without the new annonations introduced in 1.5 .
Even with the XDoclet and the Spring implmentation there are a lot of descriptors that you have to set yourself.

Over whole, with annotnations, it makes more sense to use POJO because of their many advantages, and that's the reason for the change, in my opinion (along with the successs of things like hibernate and spring).
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Originally posted by Theodore Casser:
Not that I'm the author or an expert, but my guess (based on conversations my coworkers and I have had on the topic around our office) is that it's just a matter of things simplifying over time. I'm sure they'd have thought of POJOs sooner if the language features we have now (annotations and the like) had existed. Just a matter of whatever is available at the time.

Just my thoughts.


Can't we do without annotations ? I think in Hibernate it is just enough to specify the class info in an an external file (EJB has ejb-jar.xml)and still use POJO as domain object.
Theodore Casser
Ranch Hand

Joined: Mar 14, 2001
Posts: 1902

Originally posted by Pradip Bhat:


Can't we do without annotations ? I think in Hibernate it is just enough to specify the class info in an an external file (EJB has ejb-jar.xml)and still use POJO as domain object.


If I recall correctly from what I've been seeing, even Hibernate 3 uses annotations. Yes, it certainly was easy enough in Hibernate 2 to use the external file to set things up, but bear in mind that Hibernate came well after Sun's first shot at EJBs.
pascal betz
Ranch Hand

Joined: Jun 19, 2001
Posts: 547
hibernate 3 does not mandate you to use the annotations. you can still write mapping files (.hbm files) as you did in hibernate 2.
Theodore Casser
Ranch Hand

Joined: Mar 14, 2001
Posts: 1902

Originally posted by pascal betz:
hibernate 3 does not mandate you to use the annotations. you can still write mapping files (.hbm files) as you did in hibernate 2.


I didn't think that it was required, but was just pointing out that it uses them now.

What I was trying to say is still valid, regardless - EJB3 is the way it is because of newer features in the language that make it easier to do.
Chris Richardson
author
Ranch Hand

Joined: Jan 10, 2006
Posts: 50
Hello,

My memory of the 1990s is a little hazy but I seem to recall that EJBs were somewhat based on CORBA, which was even more cumbersome than EJB 1/2.
Interesting, I think there were some transparent persistence solutions based then but sadly they were temporarily displaced as the industry promoted entity beans as the standard persistence mechanism.

Unfortunately, many of the reasons technologies are adopted in the software industry are less to do with their technical merits and a lot more to do with politics, commercial reasons and cultural issues.

Back in 1999, I readily adopted EJBs, thought they were cool and happily wrote DTOs and sat around waiting for the application server to startup. It took a while before their drawbacks set in and I started going down the POJO path.

I sometimes liken EJB to a cult (http://en.wikipedia.org/wiki/Cult). Those in the cult readily perform rituals (e.g. deployment, DTO development, writing excessively complex code etc) that those outside the cult find strange.

As a former EJB cult member...

Chris


Enterprise Java consulting and training - <a href="http://www.chrisrichardson.net" target="_blank" rel="nofollow">http://www.chrisrichardson.net</a> Author, POJOs in Action - <a href="http://www.manning.com/crichardson" target="_blank" rel="nofollow">http://www.manning.com/crichardson</a> Enterprise POJOs blog - <a href="http://chris-richardson.blog-city.com" target="_blank" rel="nofollow">http://chris-richardson.blog-city.com</a>
Chris Richardson
author
Ranch Hand

Joined: Jan 10, 2006
Posts: 50
The role of annotations is interesting (http://www.aspectprogrammer.org/blogs/adrian/2004/08/when_is_a_pojo.html).
Annotations can be more convenient than XML primarily because the annotations are next to the program element they are describing. In addition, domain-specific annotations make a lot sense.

However, one drawback of framework-specific annotations is that they couple your code to that particular framework. e.g. Using Spring's @transactional couples your code to the Spring framework and using EJB3's @EJB annotation couples your code to that framework.

This has a couple of drawbacks. First, upgrading to a newer version of the framework might mean having to chance your code. Can you be sure that the annotations in version N+1 will be backwards compatible with those in version N? Not to pick on EJB, but each version of EJB has been different from the preceding version.

Second, trying out a new version framework is inconvenient if that framework requires you to use annotations. You have to change your source code.

In comparison, keeping framework-specific metadata in an XML makes upgrading/switch frameworks a lot easier.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

In comparison, keeping framework-specific metadata in an XML makes upgrading/switch frameworks a lot easier


I agree with you. Using annotations in the source file means that if we change the framework we would need to edit the file. Putting meta data in an external file is a good option.
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626

agree with you. Using annotations in the source file means that if we change the framework we would need to edit the file. Putting meta data in an external file is a good option.


I don't understand how do you put metadata in external file. Like in Hibenate when you use xdoclet tags to define mapping it's at column=java attribute level. How do you put all the attribute mapping outside.
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1821

Usually, the metadata is stored in an XML file with the same name as the class and is found in the classpath. These files are loaded by the engine and used at runtime to handle the mappings.


Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Roy Ben Ami
Ranch Hand

Joined: Jan 13, 2002
Posts: 732
Originally posted by Jignesh Patel:


I don't understand how do you put metadata in external file. Like in Hibenate when you use xdoclet tags to define mapping it's at column=java attribute level. How do you put all the attribute mapping outside.


All XDoclet does is create the external XML mapping files for you.
It just simplifies things by letting you use Java comments instead of writing the XML files yourself.

Annonations on the other hand don't create any XML files.
They are also actual code unlike the Java comments you use in XDoclet so you can even query them at Runtime.

As people pointed out, they have their disadvantages and benefits.
Theodore Casser
Ranch Hand

Joined: Mar 14, 2001
Posts: 1902

Originally posted by Roy Ben Ami:
As people pointed out, they have their disadvantages and benefits.


Everything is a trade-off in the end.

That being said, in the (ongoing) debate about annotations vs XDoclet/external mapping, I think the annotations are a vast improvement - it's one less thing for me to forget about while coding, and it's clear in the code close to where you're doing the actual work so you can see more of the full picture while code is being written.
Roy Ben Ami
Ranch Hand

Joined: Jan 13, 2002
Posts: 732
Originally posted by Theodore Casser:

I think the annotations are a vast improvement...


I tend to agree

But again, this is just another concept Java got from the .NET world (the Meta-Data).

As much as I hate Microsoft, they did some good things with all the C# and CLR stuff.
Luckily for us, Java manages to integrate over time all the good stuff from there and leave out the crappy bits (except the import static thing which is a terrible addition ).
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1821

Originally posted by Theodore Casser:

it's one less thing for me to forget about while coding, and it's clear in the code close to where you're doing the actual work so you can see more of the full picture while code is being written.


True, although I tend to generate both my POJOs and my mappings, so I rarely actually read the code, and rarely forget to generate both. Granted, its not Hibernate that I'm using (it's my own persistance engine/generation tool), but its almost identical in concept to Hibernate (I'm sure Hibernate does it much better, though.)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why POJO was not used before