This page has been created to compare Java ObjectRelationalMapping layers. This should help potential users to make an educated choice of O/R technology and to better understand the existing products.
Why only Java? There are ObjectRelationalMapping layers in other languages.
I second that. I'd like to know of and compare a list of ObjectRelationalToolComparisonDotNet for DotNet; does anyone know of any?
This is a good point that other languages should be present too. However, purely from usability perspective, this page is already overloaded with info as it is. Any refactoring ideas to make it more readable?
Unfortunately, I don't, since WardsWiki isn't really setup to do big tables like this ... Mostly, I just think that this page title should have the word "Java" in it, is all. A small gripe. -- francis
Fabrice Marguerie published an article on the criteria to consider when choosing an object-relational mapping tool, for Java or DotNet: http://madgeek.com/Articles/ORMapping/EN/mapping.htm
There's also a vacuum (on the web, not just wiki) of comparison of PerlLanguage ORM tools - if you poke around mailing list archives and things, you'll see a lot of 1-vs-1 comparisons and people requesting a general comparison of Perl ORM and similar tools.
There is now a feature matrix provided for easier comparison. An asterisk means that there's some comments or further explanation of the item. All The comments are below the matrix in the original format, grouped by the features (Duplicate info should probably be deleted). The full descriptions of the features are right below the matrix.
Frameworks included in the comparison:
The feature matrix
(Please, no tabs in the table!)
Feature-Matrix in CSV:
FeatureMatrixCsv
IncludesMaintainsGeneratesSupportsSupportsSupportsCan fetchSupports SupportsRequiresSupportsSupportsSupportsSupports
RequiresSupportsMappingfull support singlemappingSupportsboth manycollections inheritanceassociated optimistic SupportsProvides ProvidesRequiresclusteringcodesequences andmappingmappingpersistenceSupports
Free -Free - PersistsmanualRDBMS supportrelationsMappingsupportsof lazyidentities Resolvesascompositeto many and of Strings, /Supportsobjectslockingunit of work/ SUN JDOODMGdatabasewithoutgeneration Requiresautoincrements Supportsclass tomultiplethroughpersistence
Releaseno licence sourceHas mapping arbitrarySQL/betweensupports aggregateresolutionforcircularwell asprimaryAggregate one to oneIntegers,polymorphic one to oneusing/ object level compliant complianttables for loss of/ byteruntimeQueryfor primaryternarymultipleclasses to privatethrough
Versionfeeavailable GUI classesbuilding independence EJB supportobjectsgrouping functionsof queriesobjectsidentities objectskeysmappings associations Dates, etc. queriesassociations outer joins versioning transactions APIAPI metadatatransactions processing reflection Caching key generation associations tablesone table fieldsaccessors
- 2 3 456 78910111213 14 1516171819202122 23 242526 27 2829 30 31323334 35 3637
Abra00.9.6YesYesNoNoNoJDBC *No *Yes NoNoYes *Yes *YesYes *No *No *Yes No *Yes *YesNoYesYesNoNoNoYesYes NoYes *Yes?No *Yes *NoYes *
BasicWebLib0.7iYesYesNoNoYes *?*YesYesYesNoNoNoNoYesYesYesYesYesYesYesNoNoNoNoNoNoNo No NoYes?No ???
Castor0.9.5YesYesNoYes * NoJDBC *No *Yes NoNoYes *Yes?NoYesYes *YesYes NoYesYesYes *YesNoYesNo ?No YesYes *Yes * ?Yes *No NoYes
CayenneFramework1.1YesYesYesNoNoJDBC *Yes *YesYesYesYes *Yes *YesYesYes? Yes *??YesNo *Yes *?NoNoYes *??? ???? ???
CocoBase4NoNoYesYesNoJDBC *Yes *Yes ?YesYes??YesYesYesYesYesYesYesYes *YesYesNoNoNo?NoYesYes *??? ? ??
DataBind0.4YesYesNoYesYes *JDBC *NoYesYesNoNo NoNoYesNoNoNo??NoNoNoNoNo ?NoNo YesNo??????
EdgeXtend2*NoNoYesNo *NoODBC *Yes *YesNo *No *Yes *YesYesYesYesYesYes *No *YesYesYesYesYesNo *NoNoYesYesNoNo *YesNo? Yes *??
EnterpriseObjectsFramework?No *NoYesNoNoJDBC *No *Yes No *No *Yes *Yes *YesYesYesYes *Yes?Yes *No *YesYes *YesNoNoYes *?NoYes *Yes *Yes * ?Yes *Yes??
Expresso?YesYesNoNoNoJDBC *Yes *YesYesYes???YesYesYesYes ?????YesNoNoNoNo *No????? ? ??
FireStormNo *
FrontierSuite? for J2EE & J2SE3.1NoNoYesYesNoJDBC *Yes *Yes NoYesYesYesYesYes *YesYesYesYesYes *YesYesYesYesNoNoNoYes *YesYesYesYesNoYes???
FrontierSuite? for JDO3.0 SP1NoNoYesYesNoJDBC *Yes *YesNoNo *Yes *YesYesYes *YesYesYesYesYes *YesYesYesYesYesNoNoYes *YesYesYesYesNoYes???
Hibernate3.0.2YesYesNo *YesNoJDBC *Yes *YesYesYesYes *Yes *YesYes *Yes *YesYesYes *Yes *Yes *Yes *Yes *YesNoYes *No *Yes *Yes *No *Yes *Yes *Yes *Yes (3)YesYesYes
iBATIS DB Layer2YesYesNo *Yes *Yes *JDBC *Yes *YesYes *Yes *Yes *NoNo NoYes *Yes *YesYesNoYesYesNo No * No *NoNo NoNo *YesYes *Yes * ?Yes *Yes?Yes
Infobjects ObjectDRIVERYesNo No NoYesNoODBC *No * Yes NoYesYes YesYesYesYesYesYes Yes Yes YesNo YesYesNo *Yes No YesNo No YesYesYes Yes? ??
InterSystems Cache5.0RC3 JDBC *Yes *Yes *?Yes * ?? ?Yes *Yes *? ?????? ?????? ? ??
Jakarta ObjectRelationalBridge1YesYesYes *YesNoJDBC *Yes *YesYesYesYes *YesYesYesYesYesYesYesYesYesYes Yes *YesYes *Yes *No *YesNo *No *Yes *Yes *YesYesYesYesYes
Java Ultra-Lite Persistence (JULP)1.0.1yesYesYesNoYesYesYesYesYesYesNo?NoYesYes *Yes?YesYesYesYesYes *NoNoNoNoNoYesYesYes?Yes ?YesYes
JaxorFramework2.2YesYesNoNo *NoJDBC *Yes *YesYes?Yes *YesYesYesYesYesYesYesYesYesYes *Yes *Yes * ? ?NoYesYesNoYes *??? ? ??
JdoGenie1.3.2No *NoYesYesNoJDBC *Yes *YesNoNoYes *YesYesYes *YesYes *YesYesYesYesYes *Yes *YesYesNoYes *Yes *Yes *NoYes *Yes?? ? ??
JdoMax1.0YesNoNoYesNoyesNoYesNoYesYesYesYesYesNoYesYesYesYesYesYesYesYesYesNoNoNoYesNoYesYesYesYesYesYesYesNoYesyesyes
JDX4.5NoNoYesYesNoJDBC *Yes *Yes No *YesYesYes *YesYesYesYesYesYesYesYesNo *YesNo *NoNoNo *Yes *NoYesNoYesYesYes? ??
Lychee0.01YesYesNoYesNoJDBCNoYesYesNoYesNoNoYesNoYesYesNoNoYesYesNoJDBCNoNoNoYesNoNoNoYesYesYesYesYesNoYesYesYes
KodoJdo3.3.3No *NoYes *YesNoJDBC *Yes *YesYesYesYesYesYesYesYesYesYesYesYesYesYesYes *YesYesNoNoYesYesNoYesYes?YesYesYes?
Signsoft intelliBO3.6No *NoYesYesNoJDBC *Yes *YesNoNo *YesYesYesYesYesYesYesYesYesYesYes YesYesYesNoNoYes *YesNoYes *YesNo *YesYesYesNo
SimpleOrm0.1Yes *Yes *No *No *No *JDBC **Yes *Yes *Yes *Yes *Yes *YesYes *YesNo *No *Yes **Yes * No *Yes *YesNo *No *No *No *NoNo *Yes *Yes *Yes *No ? ??
The ProductivityEnvironmentForJava (PE:J)2.2.2Yes *NoYesYesNoJDBC *Yes *YesYesYesYesYesYesYesYesYesYesYesYesYesNo *YesYesYesNoYes *YesYes *NoYesYesYesYes? ??
TopLink9.03No *No *YesYesNo *JDBC *Yes *YesYesYesYesYesYesYesYesYesYesYesYesYesYes *Yes *YesNo *NoNoYes * NoYesYes *Yes *YesYes? YesYes
VBSF3.03No NoYesYesNoJDBC *Yes *YesYes *YesYesYesYesYesYesYesYesYesYesYesNoYesYesYes *Yes *NoYes * NoYesYesYesYes Yes? ??
XIC 4.2 NoNoYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYesYes
Features included in the comparison:
0. Relationally Complete.
1. Release Version Number (To indicate which version has been referred to)
2. "Free" as in "free beer" - no license fee
3. "Free" as in "free speech" - source available
4. Has mapping GUI
5. Persists arbitrary classes (no special superclass or interface required)
6. Requires manual SQL building
7. RDBMS support/independence
8. EJB support (for whoever needs it)
9. Supports relationships between objects
10. Mapping supports grouping (GROUP BY clause)
11. Mapping supports aggregate functions (count(), avg(), etc.)
12. Includes full support of lazy resolution of all queries
13. Maintains single identities for objects returned from queries (aka "uniquing") (i.e., AddressFinder.findById(1) == AddressFinder.findById(1));
14. Resolves Circular Identities (aka "uniquing") (i.e., "account == account.getCustomer().getAccount()")
15. Generates Mapping as well as the Java Objects themselves, so you don't duplicate information in the Java Objects and the related mapping information.
Comments: (who says this is a GoodThing? I don't want my DomainObject classes' source generated by some tool)
Well, for O/R mapping you have to define somewhere the fields and how they're persisted. This usually at least consists of class, field names, and types. If you write the class and the mapping, you violate OnceAndOnlyOnce and DontRepeatYourself since the mapping file duplicates all the information that is contained in the class itself. The mapping gives you all the information you need to generate the object itself, so why not generate it? Why write code that you don't have to? There's a difference between a DomainObject and a DataAccessObject. DomainObjects have behavior-intensive methods that implement various responsibilities allocated to them from application requirements. Is the mapping tool going to generate the code for all my DomainObject's responsibilities? I doubt it. It probably generates only a simple class skeleton consisting of variable declarations and getters and setters - which I may not even want. And it probably can't preserve non-generated additions when the need arises to re-generate due to class shape or mapping changes. The DomainModel is the heart of the system - see http://domainlanguage.com/book.html - and can be written and tested before any persistence-related code is even written. Plus, what happens if you want to switch persistence technologies, such that your mapping and the tool that generates it becomes irrelevant? Many of the problems you describe relate to PassiveCodeGeneration and not ActiveCodeGeneration (regenerate at every build, NEVER MODIFY). There are ways to effectively merge business logic and generated objects. Basically it boils down to inheritance or composition, either one is effective. This is often called a the MartiniGlassArchitecture? b/c it allows you to seamlessly (ThereIsNoSuchThingAsSeamless) merge business and generated data logic into one unified DomainModel. Any tool, whether a language or a code generator, (Java and CeeSharp can also be viewed as code generators) can become obsolete. Evaluate your risks accordingly. Preferably, find an open source solution, get write access, then make sure it doesn't become obsolete. ;)
16. Supports Composite Primary Keys
17. Aggregate Mappings - Single field maps to multiple fields in database. http://martinfowler.com/eaaCatalog/embeddedValue.html
18. Supports both many to many and one to many associations
19. Supports collections of Strings, Integers, Dates, etc
20. Supports inheritance / polymorphic queries
21. Supports one to one associations
22. Can fetch associated objects using SQL outer joins
23. Support for optimistic locking / versioning
24. Support for Unit of work / object level transactions
25. Providing a SUN JDO compliant API
26. Providing an ODMG compliant API
27. Requires "extra" database tables holding locks, metadata, etc.
28. Supports multiservers (clustering) and simultaneous access by other applications without loss of transaction integrity
29. Requires code generation / bytecode processing
30. Requires RuntimeReflection?
31. Query Caching - Built-in support (developer writes no code).
The following two identical queries will hit the database only once. The second time cached results will be returned.
Address address = AddressFinder.selectByPrimaryKey(new Long(1));
assertTrue(address == AddressFinder.selectByPrimaryKey(new Long(1)));
32. Supports sequences and identity/autoincrement columns for primary key generation (Not using the incorrect SELECT MAX method!)
33. Supports ternary associations
34. Supports mapping of one class to multiple tables
Comments: Any comments on this? Is this really a useful thing to do? If the tables are badly designed, fix them!
I believe why this question can is solve by convenient UML diagram
We think this is a Bad Thing: http://www.hibernate.org/Documentation/Delegate
Sometimes legacy databases leave you no choice.
I believe that for a general purpose persistence framework, this type of support is absolutely critical. The reason is that in many development shops, different people control the object and data models. In the real world, either or both could be well designed or poorly designed. Either or both could be a legacy model, or new.
Even with good design this is desirable. Object modeling and relational modeling represent the same conceptual model differently - they cannot be expected to be 1 for 1. For example, tables are needed for many to many relationship - a class is not needed for this, as each object merely has a collection of the other.
35. Supports mapping of multiple classes to one table
36. Supports persistence of properties through private fields
37. Supports persistence of properties through accessors (get/set methods)
38. Supports disconnected operations: Populate objects from database, disconnect, create/remove/modify objects (on client, another JVM) and apply changes to database (much) later
Comments and explanations of the features
1. Release Version Number (To indicate which version has been referred to)
2. "Free" as in "free beer" - no license fee
- Abra: Yes
- BasicWebLib - YES
- DB Visual Architect - No
- Castor: Yes
- CayenneFramework: Yes
- CocoBase: No
- DataBind: Yes
- EdgeXtend: No
- EnterpriseObjectsFramework: No, but cheap ($700 that also includes WebObjects, unlimited clients and cpu)
- Expresso: Yes
- FireStorm - NO but very cheap ($200)
- FrontierSuite? for J2EE & J2SE: No(Free Evaluation Copy can be downloaded at www.objectfrontier.com)
- FrontierSuite? for JDO: No(Free Evaluation Copy can be downloaded at www.objectfrontier.com)
- Hibernate: Yes
- Hydrate: Yes
- iBATIS DB Layer - YES
- Infobjects ObjectDRIVER: NO
- Jakarta ObjectRelationalBridge: Yes
- Java Ultra-Lite Persistence (JULP): yes
- JaxorFramework: Yes
- JdoGenie: No (but free for non-commercial/academic use)
- JDX - No
- KodoJdo: No (but free for eligible non-commercial/academic use)
- LiDO: See XIC
- Lychee: Yes
- O/R Broker: Yes
- PowerMapJdo: Commercial
- Signsoft intelliBO: No (but free for eligible non-commercial/academic use)
- SimpleOrm: Free (Apache license).
- Sql2java: Free (GPL)
- The ProductivityEnvironmentForJava (PE:J): Free Limited Edition available
- TopLink: Evaluation copies can be downloaded from Oracle Technology Network. OTN licenses such downloads according to the OTN License Agreement (http://otn.oracle.com/software/htdocs/devlic.html) which basically says as soon as you are no longer evaluating/prototyping, you need to buy a license.
- VBSF: No
- XIC: No
3. "Free" as in "free speech" - source available
4. Has mapping GUI
5. Persists arbitrary classes (no special superclass or interface required)
- Abra: No
- BasicWebLib: No
- Castor: Yes (but need to implement Timestampable if reading/writing in separate tx)
- CayenneFramework: No
- CocoBase: Yes
- DataBind: Yes
- DB Visual Architect - No
- EdgeXtend: No, but developer defines interfaces using object model specification
- EnterpriseObjectsFramework: No
- Expresso: No
- FrontierSuite? for J2EE & J2SE: Yes
- FrontierSuite? for JDO: Yes
- Hibernate: Yes
- Hydrate: Yes, though see documentation to understand if you'd want to.
- iBATIS DB Layer - YES (JavaBeans, Maps, Primitive Wrappers, Collections, XML etc.)
- Infobjects ObjectDRIVER: Yes
- Jakarta ObjectRelationalBridge: Yes
- Java Ultra-Lite Persistence (JULP): No
- JaxorFramework: No (need to define a base entity)
- JdoGenie: Yes
- JDX: Yes
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: Yes (works with POJOs not requiring them to implement any interfaces or extend any classes)
- O/R Broker: Yes (True POJO support, not just JavaBeans and Maps. Respects encapsulation)
- PowerMapJdo: Yes
- Signsoft intelliBO: Yes
- SimpleOrm: No, persistence has issues that you need to be aware of.
- SpadeSoft XJDO: Yes
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes
- VBSF: Yes
- XIC: Yes
6. Requires manual SQL building
7. RDBMS support/independence
- Abra: JDBC (PostgreSQL, Oracle, Sybase, MySQL, DB2)
- Castor: DB2, HypersonicSQL, Informix, InstantDB, Interbase, MySQL, Oracle, PostgreSQL, SAP DB, SQL Server, Sybase, Generic (for generic JDBC support)
- CayenneFramework: Ships with adapters for Oracle, Sybase, MySQL, PostgreSQL, HSQLDB, Firebird, OpenBase, DB2, SQLServer, and a generic JDBC one.
- CocoBase: JDBC
- DataBind: JDBC
- DB Visual Architect: JDBC
- EdgeXtend: ODBC, optimized for Oracle, Sybase, DB2, Informix, SQLServer
- EnterpriseObjectsFramework: JDBC, but special for Oracle, OpenBase, (few others from RDBMS vendors)
- Expresso: JDBC
- FrontierSuite? for J2EE & J2SE: JDBC (Oracle, SQL Server, DB2, Sybase, Informix, MySQL, Hypersonic SQL, PointBase?, Cloudscape)
- FrontierSuite? for JDO: JDBC (Oracle, SQL Server, DB2, Sybase, Informix, MySQL, Hypersonic SQL, PointBase?, Cloudscape)
- Hibernate: JDBC, special for Oracle, DB2, Sybase, MS SQL Server, PostgreSQL, MySQL, HypersonicSQL, Mckoi SQL, SAP DB, Interbase, Progress, Pointbase
- Hydrate: most JDBC driver-supported RDBMSs
- iBATIS DB Layer - Any RDBMS that has a JDBC driver.
- Infobjects ObjectDRIVER: any ODBC compliant - optimized for Oracle via OCI
- InterSystems Cache: Can create both RDBMS or Object Schemas. Includes a class 3 JDBC driver.
- Jakarta ObjectRelationalBridge: JDBC, special dialect support for Db2, Hsqldb, Informix, MsAccess?, MsSQLServer, MySQL, Oracle, PostgreSQL, Sybase, Sapdb.
- Java Ultra-Lite Persistence (JULP): any with JDBC driver
- JaxorFramework: JDBC
- JdoGenie: JDBC (Sybase, Oracle, MySQL, DB2, Microsoft SQL Server, Informix, Informix SE, Pointbase, Interbase, Firebird, Postgres, SAP DB)
- JDX: JDBC
- KodoJdo: JDBC (Oracle, DB2, MS SQL Server, Sybase, Informix, MySQL, Postgres, Hypersonic, InstantDB, Pointbase, FoxPro, MS Access, Daffodil, Cloudscape)
- LiDO: See XIC
- Lychee: Oracle 10g, Oracle 9i, Oracle 8i
- O/R Broker: Any JDBC compliant RDBMS.
- PowerMapJdo: JDBC with special for Oracle, SQLServer, MySQL, PointBase? and others
- Signsoft intelliBO: JDBC but special for PointBase?, Oracle, MS SQL, IBM DB2, Informix, InstantDB, Interbase, MySQL, Pervasive, PostgresQL, Progress, SapDB, Sybase
- SimpleOrm: JDBC, with DB specific drivers to handle incompatibilities.
- SpadeSoft XJDO: Supports all JDBC drivers available in the market
- Sql2java: JDBC, with DB specific drivers to handle incompatibilities.
- The ProductivityEnvironmentForJava (PE:J): JDBC, optimized for Oracle, IBM DB2/UDB, MS SQLServer.
- TopLink: JDBC, special dialect support for MS Access, Cloudscape, DB2, DBase, Informix, Sybase, Oracle, PointBase? and Microsoft SQL Server.
- VBSF: JDBC
- XIC: JDBC but special for Oracle, DB2, Sybase, Informix, SQLServer, MySQL PostgreSQL, McKoi, InstantDB, HSQLDB, PointBase?, Cloudscape, Unisys
8. EJB support (for whoever needs it)
- Abra: No (why would you use it??)
- BasicWebLib - PostgreSQL support, MySQL, others planned
- Castor: No
- CayenneFramework: works just fine inside EJBs, allows both Cayenne and container transactions
- CocoBase: Yes
- DataBind: ?
- EdgeXtend: Yes
- EnterpriseObjectsFramework: No, only as a client to external beans
- Expresso: Yes
- FrontierSuite? for J2EE & J2SE: Yes. EJB CMP and BMP. EJB 2.0 and 1.1 (Weblogic, Websphere, Oracle 9i, JBoss, Orbix E2A J2EE, JRun, Orion, HP AS)
- FrontierSuite? for JDO: Yes (Weblogic, Websphere, Oracle 9i, JBoss, Orbix E2A J2EE, JRun, Orion, HP AS)
- Hibernate: support for stateful/stateless session beans and BMP entity beans, JTA, JNDI, JMX integration
- Hydrate: will work in a container
- iBATIS DB Layer - Stateful/Stateless session beans, Global Transaction (JTA), JNDI DataSources? and BMP -- Spring integration for those who dislike EJB
- Infobjects ObjectDRIVER: No, not yet
- InterSystems Cache: Yes - define the table and it spits out the EJBs.
- Jakarta ObjectRelationalBridge: full support for SessionBeans and BMP EntityBeans, JNDI, JTA & JCA integration
- Java Ultra-Lite Persistence (JULP): yes
- JaxorFramework: Yes, designed to run within any J2EE container, or can run outside of container.
- JdoGenie: Yes
- JDX: Yes (BMP and O/R Mapping for SessionBeans, JNDI)
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: No
- O/R Broker: Yes
- PowerMapJdo: Supports container environment
- Signsoft intelliBO: Yes
- SimpleOrm: Session Beans Supported. Entity Beans are not simple to use!
- SpadeSoft XJDO: Yes
- Sql2java: No
- The ProductivityEnvironmentForJava (PE:J): auto-generates configurable Session EJB facade layer with JDO Persistence, support for BMP Entity EJB, JNDI, JTA, and JCA Integration
- TopLink: Yes - BMP; CMP 1.1, CMP 2.0; Session beans + JTA integration
- VBSF: Yes
- XIC: Yes
9. Supports relationships between objects
10. Mapping supports grouping (GROUP BY clause)
11. Mapping supports aggregate functions (count(), avg(), etc.)
12. Includes full support of lazy resolution of all queries
- Abra: Sort of (some developer code is needed to determine how much is retrieved and when)
- BasicWebLib - NO
- Castor: Yes (Lazy Loading)
- CayenneFramework: Yes, lazy relationship reading, object "faults" (dynamic proxies)
- CocoBase: Yes
- DataBind: No
- DB Visual Architect: Yes
- EdgeXtend: Yes, provides lazy fetch of database queries
- EnterpriseObjectsFramework: Yes, lazy relationship reading, object "faults" (dynamic proxies)
- Expresso: ?
- FrontierSuite? for J2EE & J2SE: Yes
- FrontierSuite? for JDO: Yes (Within JDO scope)
- Hibernate: Yes, object "faults" (runtime CGLIB bytecode-generation for proxies), lazy relationship reading
- Hydrate: Yes, but why should you if you can load any number of dependent objects without running subqueries?
- iBATIS DB Layer - YES (w/cglib), Collections, Lists and PaginatedList? (List impl. with pages, next/prev functions etc.)
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: ?
- Jakarta ObjectRelationalBridge: Yes + dynamic proxies for all relationships
- Java Ultra-Lite Persistence (JULP): no
- JaxorFramework: Uses lazy dynamic proxies, so developers never have to write their own lazy code.
- JdoGenie: Yes (fully transparent - no proxies etc.)
- JDX: Yes
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: Yes, lazy relationship loading.
- O/R Broker: On sub-queries that map to java.util.Collection interface.
- PowerMapJdo: Yes
- Signsoft intelliBO: Yes
- SimpleOrm: Yes, lazy relationship loading and delayed query execution.
- SpadeSoft XJDO: Yes
- Sql2java: Yes
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes
- VBSF: Yes
- XIC: Yes
13. Maintains single identities for objects returned from queries (aka "uniquing") (i.e., A
ddressFinder.findById(1) == A
ddressFinder.findById(1));
- Abra: Yes (by object ID)
- BasicWebLib - NO
- Castor: Yes
- CayenneFramework: Yes (normally in the session scope, but can be done in any scope you want)
- CocoBase: ?
- DataBind: No
- DB Visual Architect: Yes
- EdgeXtend: Yes
- EnterpriseObjectsFramework: Yes (in and outside of the application scope)
- Expresso: ?
- FrontierSuite? for J2EE & J2SE: Yes
- FrontierSuite? for JDO: Yes
- Hibernate: some proxy issues (in the session scope)
- Hydrate: Yes, strict.
- iBATIS DB Layer: No
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: ?
- Jakarta ObjectRelationalBridge: Yes
- Java Ultra-Lite Persistence (JULP): ?
- JaxorFramework: Yes
- JdoGenie: Yes
- JDX: Yes (intra-query)
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: No (Will be two different instances in memory that are equal. Was intentionally designed not to use object caching to avoid hassle associated with it.)
- O/R Broker: Yes, within same Query or Transaction session. Outside of that would not be threadsafe.
- PowerMapJdo: Yes
- Signsoft intelliBO: Yes
- SimpleOrm: Yes, and with multi field primary keys. (I do not think that a tool can be called an ORM if it does not do this.)
- SpadeSoft XJDO: Yes
- Sql2java: Yes
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes
- VBSF: Yes
- XIC: Yes
14. Resolves Circular Identities (aka "uniquing") (i.e., "account == account.getCustomer().getAccount()")
15. Generates Mapping as well as the Java Objects themselves, so you don't duplicate information in the Java Objects and the related mapping information.
- Abra: Yes (Mapping, SQL, and classes are all generated from XML; also the above always generate/ and business code can be solved by using our 'descendant' pattern. In this a class defined in the map file, (which is generated every build) can have a descendant which is where the business/application code will go. In the mapping-factories when retrieving from the database the generated code knows to create the instance of the descendant class (which is a hand-written class containing business methods))
- BasicWebLib - NO
- Castor: No
- CayenneFramework: Yes
- CocoBase: Yes
- DataBind: No
- EdgeXtend: Yes
- EnterpriseObjectsFramework: Yes
- Expresso: Yes
- FrontierSuite? for J2EE & J2SE: Yes. Both code and mapping information is generated from an object model through support for Model Driven Architecture (MDA). The behaviour intensive methods aka business logic is maintained separately from the model so that any domain model changes do not result in a loss of these methods.
- FrontierSuite? for JDO: Yes. Both code and mapping information is generated from an object model through support for Model Driven Architecture (MDA). The behaviour intensive methods aka business logic is maintained separately from the model so that any domain model changes do not result in a loss of these methods.
- Hibernate: Yes (support for multiple development models; Java first, mapping first, table first, Java/XDoclet first)
- Hydrate: Yes - code generation used to generate basic bean interfaces and classes if you want to use them.
- iBATIS DB Layer: No (by design, generally agree with the comment below)
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: Yes -- it is a fully object-relational DB, so you define the database "Classes" and it generates the Java Objects.
- Jakarta ObjectRelationalBridge: Yes
- Java Ultra-Lite Persistence (JULP): yes
- JaxorFramework: Yes
- JdoGenie: Yes (generates mappings from classes)
- JDX: Yes
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: Yes, can generate java objects out of the XML mapping file.
- O/R Broker: No thanks.
- PowerMapJdo: Forward/ reverse engineering features
- Signsoft intelliBO: Yes
- SimpleOrm: Yes! The big feature of SimpleOrm is that these are actually the same thing due to its generalized design. A single source of truth.
- SpadeSoft XJDO: Yes
- Sql2java: Yes
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes
- VBSF: Yes
- XIC: Yes
Comments:
(who says this is a GoodThing? I don't want my DomainObject classes' source generated by some tool)
Well, for O/R mapping you have to define somewhere the fields and how they're persisted. This usually at least consists of class, field names, and types. If you write the class and the mapping, you violate OnceAndOnlyOnce and DontRepeatYourself since the mapping file duplicates all the information that is contained in the class itself. The mapping gives you all the information you need to generate the object itself, so why not generate it? Why write code that you don't have to? There's a difference between a DomainObject and a DataAccessObject. DomainObjects have behavior-intensive methods that implement various responsibilities allocated to them from application requirements. Is the mapping tool going to generate the code for all my DomainObject's responsibilities? I doubt it. It probably generates only a simple class skeleton consisting of variable declarations and getters and setters - which I may not even want. And it probably can't preserve non-generated additions when the need arises to re-generate due to class shape or mapping changes. The DomainModel is the heart of the system - see http://domainlanguage.com/book.html - and can be written and tested before any persistence-related code is even written. Plus, what happens if you want to switch persistence technologies, such that your mapping and the tool that generates it becomes irrelevant? Many of the problems you describe relate to PassiveCodeGeneration and not ActiveCodeGeneration (regenerate at every build, NEVER MODIFY). There are ways to effectively merge business logic and generated objects. Basically it boils down to inheritance or composition, either one is effective. This is often called a the MartiniGlassArchitecture? b/c it allows you to seamlessly (ThereIsNoSuchThingAsSeamless) merge business and generated data logic into one unified DomainModel. Any tool, whether a language or a code generator, (Java and CeeSharp can also be viewed as code generators) can become obsolete. Evaluate your risks accordingly. Preferably, find an open source solution, get write access, then make sure it doesn't become obsolete. ;)
Note that this problem can be side-stepped if you're using a language with decent RuntimeReflection?, like RubyLanguage, PythonLanguage, or SmalltalkLanguage. -- francis
16. Supports Composite Primary Keys
- Abra: No (We think that primary keys should be unique DB ids not related to any business specification)
- BasicWebLib - YES
- Castor: Yes
- CayenneFramework: Yes
- CocoBase: Yes
- DataBind: Yes
- EdgeXtend: Yes
- EnterpriseObjectsFramework: Yes
- Expresso: Yes
- FrontierSuite? for J2EE & J2SE: Yes
- FrontierSuite? for JDO: Yes
- Hibernate: Yes (separate primary key class, or "embedded" key as subset of object properties)
- Hydrate: Yes, including keys of keys.
- iBATIS DB Layer - YES (for foreign key relationships as well)
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: All objects have a unique Object ID (OID), but you can override these and create your own keys if you are dealing with relational tables.
- Jakarta ObjectRelationalBridge: Yes
- Java Ultra-Lite Persistence (JULP): yes
- JaxorFramework: Yes
- JdoGenie: Yes
- JDX: Yes
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: No
- O/R Broker: Yes
- PowerMapJdo: Advanced support for mapped, composite, hybrid keys
- Signsoft intelliBO: Yes
- SimpleOrm: Yes
- SpadeSoft XJDO: Yes
- Sql2java: No (we focus on simplicity)
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes
- VBSF: Yes
- XIC: Yes
17. Aggregate Mappings - Single field maps to multiple fields in database. http://martinfowler.com/eaaCatalog/embeddedValue.html
18. Supports both many to many and one to many associations
19. Supports collections of Strings, Integers, Dates, etc
20. Supports inheritance / polymorphic queries
- Abra: Yes (but stores only leaf classes)
- BasicWebLib - YES
- Castor: No
- CayenneFramework: Yes
- CocoBase: Yes
- DataBind: ?
- EdgeXtend: Yes
- EnterpriseObjectsFramework: Yes, three different models: single table, vertical and horizontal mapping. Supports "deep" fetches on super entities.
- Expresso: ?
- FrontierSuite? for J2EE & J2SE: Yes. All three mapping models - Vertical, Horizontal and Collapsed mapping.
- FrontierSuite? for JDO: Yes. All three mapping models - Vertical, Horizontal and Collapsed mapping.
- Hibernate: Yes (all three mapping strategies: table-per-hierarchy, table-per-concrete-class, table-per-subclass)
- Hydrate: Yes
- iBATIS DB Layer - NO
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: ?
- Jakarta ObjectRelationalBridge: Yes
- Java Ultra-Lite Persistence (JULP): yes
- JaxorFramework: Yes
- JdoGenie: Yes
- JDX: Yes
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: No
- O/R Broker: Yes, polymorphic queries are possible through the template languages, of which Velocity and FreeMarker are currently supported.
- PowerMapJdo: Advanced support, query on extent, advanced union processing
- Signsoft intelliBO: Yes
- SimpleOrm: Depends what is really meant.
- SpadeSoft XJDO: Yes
- Sql2java: ?
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes
- VBSF: Yes
- XIC: Yes
21. Supports one to one associations
22. Can fetch associated objects using SQL outer joins
23. Support for optimistic locking / versioning
- Abra: Yes
- BasicWebLib - NO
- Castor: Yes (uses timestamping)
- CayenneFramework: Yes
- CocoBase: Yes
- DataBind: No
- EdgeXtend: Yes
- EnterpriseObjectsFramework: Yes, automatic field-level locking using snapshotting.
- Expresso: ?
- FrontierSuite? for J2EE & J2SE: Yes
- FrontierSuite? for JDO: Yes
- Hibernate: Yes (version numbers or timestamps)
- Hydrate: Manual
- iBATIS DB Layer: Yes (manually coded)
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: ?
- Jakarta ObjectRelationalBridge: Yes (version numbers or timestamps)
- Java Ultra-Lite Persistence (JULP): yes
- JaxorFramework: Yes (any combination of version numbers, timestamps, primary key, or any other field)
- JdoGenie: Yes (version number, timestamp, original value in where clause etc)
- JDX: Yes
- KodoJdo: Yes (version number, timestamp, state image, custom)
- LiDO: See XIC
- Lychee: No
- O/R Broker: Yes.
- PowerMapJdo: Advanced support, incl transparent integration
- Signsoft intelliBO: Yes
- SimpleOrm: Yes. (This is essential for HTTP work.)
* SpadeSoft XJDO: Yes (version numbers, timestamp, user defined versioning)
- Sql2java: Yes (manually coded)
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes i) version numbers ii) timestamps iii) field-locking on any of AllFields?, ChangedOnlyFields? or UserDefinedGroupOfFields?
- VBSF: Yes
- XIC: Yes
24. Support for Unit of work / object level transactions
- Abra: Yes
- BasicWebLib - NO
- Castor: Yes
- CayenneFramework: Cayenne implements something called DataContext? for both editing and fetching - this is the same thing but is much more usable then UOW
- CocoBase: Yes
- DataBind: No
- EdgeXtend: Yes
- EnterpriseObjectsFramework: Yes
- Expresso: Yes
- FrontierSuite? for J2EE & J2SE: Yes
- FrontierSuite? for JDO: Yes
- Hibernate: Yes
- Hydrate: Basic
- iBATIS DB Layer - NO (supports both local and global transactions, but not object level)
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: ?
- Jakarta ObjectRelationalBridge: Yes
- Java Ultra-Lite Persistence (JULP): yes(UOW)
- JaxorFramework: Yes (Default implementation and Pluggable API)
- JdoGenie: Yes
- JDX: No UOW but sophisticated transaction support including object level transactions
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: No, relies on database/container transactions.
- O/R Broker: No, but supports JDBC transactions.
- PowerMapJdo: Yes
- Signsoft intelliBO: Yes
- SimpleOrm: Yes
* SpadeSoft XJDO: Yes
25. Providing a SUN JDO compliant API
26. Providing an ODMG compliant API
27. Requires "extra" database tables holding locks, metadata, etc.
- Abra: No
- BasicWebLib: No
- Castor: No
- CayenneFramework: For automated primary key generation only.
- CocoBase: No
- DataBind: ?
- EdgeXtend: No
- EnterpriseObjectsFramework: No
- Expresso: No
- FrontierSuite? for J2EE & J2SE: No
- FrontierSuite? for JDO: No
- Hibernate: No (Only one of the key generation strategies requires it)
- Hydrate: No
- iBATIS DB Layer: No
- Infobjects ObjectDRIVER: No
- Jakarta ObjectRelationalBridge: No (only for a certain sequence number strategy and other special features)
- Java Ultra-Lite Persistence (JULP): No
- JaxorFramework: No
- JdoGenie: For automated primary key generation only.
- JDX: Optional
- KodoJdo: No
- LiDO: See XIC
- Lychee: No
- O/R Broker: No.
- PowerMapJdo: Advanced transparent integration features, for seamless integration w existing and concurrent apps
- Signsoft intelliBO: No
- SimpleOrm: No, but one should use Postgre/Oracle sequence objects when generating unique keys.
- SpadeSoft XJDO: No
- Sql2java: No
- The ProductivityEnvironmentForJava (PE:J): For auto-generated Primary Keys (for support of Datastore Identity in JDO)
- TopLink: No
- VBSF: No
- XIC: Yes
28. Supports multiservers (clustering) and simultaneous access by other applications without loss of transaction integrity
- Abra: Yes
- BasicWebLib - NO
- Castor: ?
- CayenneFramework: Yes, via JGroups and JMS
- CocoBase: ?
- DataBind: No
- EdgeXtend: Yes
- EnterpriseObjectsFramework: Yes (With JMS based distributed caching sync on choosen entities only)
- Expresso: Working on
- FrontierSuite? for J2EE & J2SE: Yes (With JMS/Multicast based distributed caching)
- FrontierSuite? for JDO: Yes (With JMS/Multicast based distributed caching)
- Hibernate: Yes (including clustered cache)
- Hydrate: With a transaction server.
- iBATIS DB Layer: Yes
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: ?
- Jakarta ObjectRelationalBridge: Yes
- Java Ultra-Lite Persistence (JULP): no
- JaxorFramework: Yes
- JdoGenie: Yes (pluggable cache API)
- JDX: Yes (using pessimistic locking)
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: Yes, due to not using any object caching.
- O/R Broker: Yes
- PowerMapJdo: Yes, focus on database integration and concurrency w existing systems
- Signsoft intelliBO: Yes (JMS, TCP, ...)
- SimpleOrm: No, not simple (except via DB).
- SpadeSoft XJDO: Yes (Very high performance)
- Sql2java: No
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes (distributed cache synchronization included - via RMI/IIOP, JMS, role-your-own)
- VBSF: Yes (by by-passing cache or refreshing cache from db, future cache synchronization mechanism planned)
- XIC: Yes
29. Requires code generation / bytecode processing
- Abra: Yes
- BasicWebLib - NO (optional for certain features)
- Castor: No
- CayenneFramework: No, everything is POJO
- CocoBase: No
- DataBind: No
- EdgeXtend: Yes
- EnterpriseObjectsFramework: No
- Expresso: No
- FrontierSuite? for J2EE & J2SE: Yes
- FrontierSuite? for JDO: Yes
- Hibernate: Yes, but at runtime, not buildtime
- Hydrate: Yes, buildtime for performance.
- iBATIS DB Layer - NO (but optional for transparent performance optimization)
- Infobjects ObjectDRIVER: No
- Jakarta ObjectRelationalBridge: No for kernel and ODMG API, Yes for JDO Api
- Java Ultra-Lite Persistence (JULP): no
- JaxorFramework: Yes
- JdoGenie: Yes (JDO bytecode enhancement)
- JDX: No
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: No
- O/R Broker: No.
- PowerMapJdo: Yes, high performance data transfer
- Signsoft intelliBO: Yes
- SimpleOrm: Absolutely not.
* SpadeSoft XJDO: Yes (Built in enhancer or any standard JDO enhancer)
- Sql2java: Yes, it generates java code very readable via javadoc
- The ProductivityEnvironmentForJava (PE:J): Only JDO vendor that provides source-code enhancement so users can see the JDO enhancements for themselves.
- TopLink: No
- VBSF: No
- XIC: Yes, JDO standard enhancement
30. Requires RuntimeReflection?
31. Query Caching - Built-in support (developer writes no code).
The following two identical queries will hit the database only once. The second time cached results will be returned.
Address address = AddressFinder.selectByPrimaryKey(new Long(1));
assertTrue(address == AddressFinder.selectByPrimaryKey(new Long(1)));
- Abra: Yes (also if lookup is by OID, or done with query set)
- BasicWebLib - NO
- Castor: Yes (Persistent instance caching: count-limited | time-limited | unlimited)
- CayenneFramework: ?
- CocoBase: Yes. Also supports integration with 3rd party caching software.
- DataBind: No
- EdgeXtend: No, but previously queried objects are cached in memory and provides cache-only queries
- EnterpriseObjectsFramework: Yes, if you want to
- Expresso: ?
- FrontierSuite? for J2EE & J2SE: Yes
- FrontierSuite? for JDO: Yes
- Hibernate: Yes. Hibernate Dual Layer Cache Architecture - session level + JVM level caching + query result set caching (also PreparedStatement caching)
- Hydrate: Yes
- iBATIS DB Layer - YES (JVM level + PreparedStatement cache)
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: ?
- Jakarta ObjectRelationalBridge: Yes (PreparedStatement caching and persistent instance caching)
- Java Ultra-Lite Persistence (JULP): yes
- JaxorFramework: Yes (Default Implementation and Pluggable API)
- JdoGenie: Yes (for primary key lookup and JDOQL queries)
- JDX: Yes
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: No (Was intentionally designed not to use object caching to avoid hassle associated with it)
- O/R Broker: No. Is not threadsafe for mutable objects. That's better left to RDBMS, JDBC, or DAO layer.
- PowerMapJdo: Yes.
- Signsoft intelliBO: Yes (primary key based, in memory, ...)
- SimpleOrm: Yes. Again this is pretty much mandatory.
- SpadeSoft XJDO: Yes
- Sql2java: Yes (manually coded)
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes; primary key-based caching, prepared-statement caching, partial but ineffective support for caching of results from arbitrary user queries; maintains transactional integrity by conforming the results against current unit-of-work state; in-memory querying.
- VBSF: Yes
- XIC: Yes
32. Supports sequences and identity/autoincrement columns for primary key generation (Not using the incorrect SELECT MAX method!)
- Abra: Yes.
- BasicWebLib - YES
- Castor: Yes. (also has hi/lo, uuid, sequence, etc)
- CayenneFramework: sequences and a few other strategies are supported
- CocoBase: ?
- DataBind: ?
- EdgeXtend: Yes
- EnterpriseObjectsFramework: Yes, including standalone unique sequence number (aka. not sql sequence generated)
- Expresso: ?
- FrontierSuite? for J2EE & J2SE: Yes
- FrontierSuite? for JDO: Yes
- Hibernate: Yes. both sequences and identity columns (also hi/lo, uuid, etc. as well as user defined strategies)
- Hydrate: Identity columns
- iBATIS DB Layer - YES (supports it, but not automated)
- Infobjects ObjectDRIVER: Yes
- InterSystems Cache: ?
- Jakarta ObjectRelationalBridge: Yes. (also has hi/lo, uuid, and user defined strategies)
- Java Ultra-Lite Persistence (JULP): yes
- JaxorFramework: ?
- JdoGenie: Yes
- JDX: Yes
- KodoJdo: Yes
- LiDO: See XIC
- Lychee: Yes, with custom implementation of IdProvider? interface.
- O/R Broker: Yes, if RDBMS supports it.
- PowerMapJdo: Yes
- Signsoft intelliBO: Yes
- SimpleOrm: Yes, and safely.
- SpadeSoft XJDO: Yes
- Sql2java: Yes
- The ProductivityEnvironmentForJava (PE:J): Yes
- TopLink: Yes - auto-generated Primary Keys can be derived from a table; alternatively, PK's can be derived from an IDENTITY column (SYBASE, MS-SQLServer, etc) or Oracle sequences.
- VBSF: Yes
- XIC: Yes
33. Supports ternary associations
The "ternary relationship" entries look a bit misleading. Please double check that, and provide documentation. For example TopLink and ObjectRelationalBridge provide no easily accessible official documentation of how they support such a feature (if indeed they support), or if they provide that they keep it very well hidden. Workarounds do not qualify as support, I'd expect that the same documentation that provides extended discussion of One to One, One To Many and Many to Many (usually mapped to first class objects in the API, and first class entities in the XML configuration file ) should provide a clarifying example/discussion of n-ary relationship concept, backed by the corresponding entry in the API or XML.
For whatever reason ObjectRelationalMapping makes for lots of passion, witness the inordinate amount of open source projects, a sign that a great deal of good developers preferred a "roll your own" solution. So we need to try to keep this discussion relatively to the level of a little more than marketing material checkboxes.
34. Supports mapping of one class to multiple tables
Comments: Any comments on this? Is this really a useful thing to do? If the tables are badly designed, fix them!
I believe why this question can is solve by convenient UML diagram
We think this is a Bad Thing: http://www.hibernate.org/Documentation/Delegate
Sometimes legacy databases leave you no choice.
I believe that for a general purpose persistence framework, this type of support is absolutely critical. The reason is that in many development shops, different people control the object and data models. In the real world, either or both could be well designed or poorly designed. Either or both could be a legacy model, or new.
35. Supports mapping of multiple classes to one table
36. Supports persistence of properties through private fields
37. Supports persistence of properties through accessors (get/set methods)
Other questions
38. Supports disconnected operations: Populate objects from database, disconnect, create/remove/modify objects (on client, another JVM) and apply changes to database (much) later
- Hibernate: yes
- Hydrate: yes
- Java Ultra-Lite Persistence (JULP): yes
- JDX: Yes
- KodoJdo: Yes
- Lychee: Yes, totally avoids the hassle of objects being attached/detached to/from sessions.
- O/R Broker: Yes.
- SpadeSoft XJDO: Yes (supporting JDO 2.0 attach/detach architecture)
- XIC: Yes
39. Supports logging all the executed SQL statements in a SQL file ?
40. Supports an API allowing to invalidate part of the cache (for example when the database is updated directly)?
- CayenneFramework: Yes
- EnterpriseObjectsFramework: Yes (per instance or per entity, including on a time basis)
- Hibernate: yes (per instance or per class)
- JDX: Yes (per instance or per class or for all classes)
- KodoJdo: Yes
- Lychee: No (Does not have cache. Was intentionally designed not to use object caching to avoid hassle associated with it)
- O/R Broker: No, caching is not supported. Better done in DAO layer.
- SpadeSoft XJDO: Yes
- Sql2java: Yes
- XIC: Yes
41. Supports massive updates (with batch and transaction size tuning)?
- CayenneFramework: Yes In fact update batching is built into Cayenne
- EnterpriseObjectsFramework: Yes
- Hydrate: Yes
- JDX: Yes (size depends upon the predicate)
- KodoJdo: Yes
- Lychee: Yes, full batched statements support (supports batching of inserts, updates and even selects)
- O/R Broker: Yes.
- SpadeSoft XJDO: Yes
- Sql2java: No
- XIC: Yes
42. Supports Date/Timestamp mapping with correct time zone?
43. Supports mapping of immutable objects?
- KodoJdo: Yes
- O/R Broker: Yes
- XIC: Yes
See also FavoriteObjectRelationalTools