commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <>
Subject [PROPOSAL] Commons Runtime API for Persistence
Date Sat, 02 Apr 2005 02:03:18 GMT

a.k.a. "Commons Persisting"

There are an increasing number of viable APIs for persisting objects to 
data stores.  We currently have JDO, a JCP spec, Hibernate, a popular 
open source project, OJB, an Apache open source project, EJB3, a new 
JCP spec for object persistence,  commercial products such as Toplink, 
and many others such as Abra, BasicWebLib, Castor, Cayenne, DataBind, 
DBVisual Architect, EnterpriseObjectsFrameworks, Expresso, FireStorm, 
iBATIS, Infobjects, InterSystems Cache, JULP, Jaxor, JDX, Kodo, LiDO, 
O/R Broker, Planet J's WOW, intelliBO, SimplOrm, Spadesoft XJDO, 
Sql2Java, PE:J, VBSF and others.

Each of these solutions have strengths and weaknesses and are chosen by 
developers based on specific project needs, political considerations, 
or quality of golf outings provided by the technology salesperson.

Like the situation that developed a few years ago with logging, in 
which developers were forced to choose between the de-facto standard, 
Apache Log4J, or the JCP-defined spec, java.util.logging, we believe 
that we have a similar situation today - developers are forced to 
commit to an API or product for persisting objects which may limit 
usefulness to users who may have a legacy persisting technology, or 
choose an different technology than the software was developed for.  
Further, there is no way to insulate software from "API lock-in", to 
allow software to be used with different persisting APIs as style, fads 
and technology concerns dictate.  Finally, there is no way to ensure 
that arbitrary dependencies that a project uses can, in an ad-hoc way, 
find and write to the application's data store.  In the same way that 
components using commons-logging never cease to delight and surprise 
users, we think that commons persisting should just enhance the mystery 
and intrigue of adding apparently innocuous dependencies to a project.


Following the successful model of "Commons Logging", we propose to 
create a single API, to be known as "Commons Persisting" which allows 
isolation from the fashions and trends in persisting technology.

This API will not :

- define a query language similar to any other
- define a query language conforming to standard set thEory
- define an O/R mapping metadata syntax
- define rules for object lifecycle with respect to the methods in this 
- use <insert favorite unproven technology here>
- constrain the types of objects and object models that a given plug-in 
might support
- keep Hani quiet

This API will :

- allow users to use one set of simple interfaces for persisting objects
- allow different providers to be "plugged-in"
- define an API for execution of queries
- piss off various and sundry expert group members


Geir Magnusson Jr                                  +1-203-665-6437

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message