Wednesday, October 16, 2002


Java Persistence Frameworks, again.

... and that is just a few of the recent posts ...

The topic of Java persistence frameworks just keeps on trucking through the Java blogs.  I think that the reason the topic keeps coming up is that there is no clear concensus on the "right way" to do persistence. I certainly don't know the right way. But anyway...

I'd like to understand the available tools a little better, so I've started looking at the tools mentioned in the above posts.  I found the feature comparison on the Cayenne project's Wiki to be helpful and I also found a very nice set of Java persistence framework development scenarios on the Hibernate website.  The Hibernate folks have outlined four development scenerios for using a Java persistence framework: top-down, bottom-up, middle-out, and meet-in-the-middle.  Here is my generalized description of these four scenarios, plus a fifth "generic-object" approach that I have added to accomodate OFBiz-EE:

Top-down: Start with an existing JavaBeans object model, develop a mapping that maps those objects to tables in your database, generate DDL to create your database, and then use a persistance API to persist those objects to that database.

Bottom-up: Start with an existing database schema, describe your database schema using using XML or some other meta-data representation, generate your JavaBeans object model, optionally add business logic to those objects, and use a persistence API to store and retrieve your objects.

Middle-out: Start with a meta-data description of your object model, generate your JavaBeans object model, generate DDL to create your dataBase, and use a persistence API to store and retrieve your objects.

Meet-in-the-middle: Start with an existing database schema and an existing JavaBeans object model, develop a mapping to map between the two, and use a persistence API to store and retrieve your objects.Generic-object: Start with a meta-data description of your desired database schema, generate DDL to create your database, and use a persistence API to store and retrieve generic data objects, with values stored as a hash of name-value pairs, to and from your database.

I think the Hibernate guys have really nailed it.  Every tool I have seen supports one or more of these scenarios.  So I decided to use these scenarios as a way to compare the available Java persistence frameworks.  I started to build a table to compare the scenarios supported by the various persistence frameworks and some other factors that I think are important interesting (thanks ceperez): support for the JDO API, support for ODMG API, development activity, and database support.  

Here is the first cut of my comparson table, I will be trying to complete it over the next couple of days:


Abra

Castor
JDO
Cayenne Commons
SQL

Hiber
-nate
Jakarta
OJB
OFBiz
EE
Jakarta
Torque

TJDO
Top-down Y
Y
Y
Y
Y
Y
N
N
Y
Bottom-up
Y


Y

N
Y

Middle-out Y
Y
Y
Y
Y

N
Y

Meet-in-middle
Y


Y

N N

Generic-object






Y


JDO API
N
N
N
N
N
soon N
N
Y
ODMG3 API

subset
N
N
Y
Y
N
N

License BSD BSD BSD
APL
LGPL
APL
BSD APL APL
Last release 0.9.6
Sept
2002
0.9.3.21
August
2002
1.0a3
Sept
2002

1.1.4-b
Oct
2002

2.0-b2
July
2002

2.0-b
Sept
2002
SF Activity
19.4% -
98.3%
- 99.9%
- 98.9% - 95.3%
SF Downloads 7
-
2698
-
775
- 86869
- 278
Developers 3

3
3
11
17
11 (1)
10 (2)
7
MySQL Y
Y
Y

Y
Y
Y
Y

PostgreSQL Y
Y


Y
Y
Y
Y

HSQL
Y


Y

Y
Y

Oracle Y
Y
Y

Y
Y
Y
Y

SQL Server
Y


Y

Y
Y

DB2 Y
Y


Y
Y
Y
Y

Sybase
Y
Y
Y

Y

Y
Y


Footnotes:
  1. There are 11 developers on OFBiz, not sure how many really work on the Entity Engine
  2. There are 10 developers on Turbine, not sure how many really work on Torque
Other notes:
  • I took JGrinder and JRF out of he mix because they seem to be a little too intrusive.  They force your to make your persistent objects extend framework objects and they don't seem to offer any tools to help you generate DDL or persistent objects.
  • I'm going to limit myself to open source frameworks for the time being, but I'd also like to consider Oracle's TopLink, CocoBase, Oracle's BC4J, and the commercial JDO implementations.  
  • I'm also going to ignore EJB CMP for now.
  • Blank cells still need to be filled in and hints are appreciated
  • A dash "-" indicates "not applicable.
By the way, Roller uses the bottom-up approach.  Roller uses Castor, but not the Castor Source Generator.  Instead, Roller uses XDoclet to generate the persistent data objects, Struts form beans, and the Castor Mapping file all from the same source meta-data.  The Castor/XDoclet combo is not perfect, but I still don't know that moving to a new framework would be an improvement.  We might just be exchanging one set of idiosyncracies for another set. [Blogging Roller]
8:09:26 AM