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:'''
	* Abra - http://abra.sourceforge.net
	* BasicWebLib - http://basicportal.sourceforge.net/
	* Castor - http://castor.exolab.org
	* Cayenne - http://objectstyle.org/cayenne/
	* DataBind - http://databind.sourceforge.net
	* DB VisualArchitect - http://www.visual-paradigm.com/dbva.php
	* EnterpriseObjectsFramework - http://www.apple.com/webobjects/
	* Expresso - http://www.jcorporate.com
	* FireStorm - http://www.codefutures.com/products/firestorm
	* Hibernate - http://www.hibernate.org
* Hydrate - http://hydrate.sourceforge.net
	* iBATIS DB Layer - http://www.ibatis.com
	* Infobjects ObjectDRIVER- http://www.infobjects.com
	* InterSystems Cache - http://www.intersystems.com
	* Jakarta ObjectRelationalBridge - http://db.apache.org/ojb
	* Java Ultra-Lite Persistence (JULP) - http://julp.sourceforge.net
	* Jaxor - http://jaxor.sourceforge.net
	* JdoGenie - http://www.jdogenie.com
	* JDOMax - http://www.jdomax.com
	* JDX - http://www.softwaretree.com
	* KodoJdo - http://www.solarmetric.com/Software/Kodo_JDO/
	* LiDO - see Xcalia Intermediation Core (XIC) - http://www.xcalia.com/products/core.jsp
	* Lychee - http://www.lycheemapper.org
	* O/R Broker - http://orbroker.sourceforge.net/
	* Persistence EdgeXtend - http://www.persistence.com/products/edgextend/
	* PlanetJ's WOW = http://planetjavainc.com/wow.html
	* PowerMapJdo - http://www.powermapjdo.com
	* Signsoft intelliBO - http://www.intellibo.com
	* SimpleOrm - http://www.SimpleOrm.org
	* SpadeSoft XJDO - http://www.spadesoft.com
	* Sql2java - http://sql2java.sf.net
	* Sun Microsystem certified (SunTone) - FrontierSuite for J2EE & J2SE - http://www.objectfrontier.com
	* Sun Microsystem certified (SunTone) - FrontierSuite for JDO - http://www.objectfrontier.com
	* The ProductivityEnvironmentForJava (PE:J) - http://www.hywy.com/
	* TopLink - http://otn.oracle.com/products/ias/toplink/content.html
	* VBSF - http://www.objectmatter.com
	* Xcalia Intermediation Core (XIC) - http://www.xcalia.com/products/core.jsp

''' The feature matrix'''
''' (Please, no tabs in the table!)'''
Feature-Matrix in CSV: FeatureMatrixCsv
																							Includes	Maintains		Generates			Supports	Supports	Supports			Can fetch	Supports						  Supports	Requires			Supports			Supports	Supports	Supports 
														Requires				Supports		Mapping	full support single		mapping	Supports		both many	collections  inheritance		associated  optimistic Supports	Provides  Provides	Requires	clustering	code				sequences and		mapping	mapping	persistence	Supports
								Free -	Free -		  Persists	manual	RDBMS support		relations	Mapping	supports	of lazy	identities Resolves	as	composite		to many and  of Strings,  /		Supports	objects	locking	unit of work/ SUN JDO	ODMG	database	without	generation  Requires		autoincrements Supports	class to	multiple	through	persistence
						Release	no licence source	Has mapping  arbitrary	SQL	/				between	supports  aggregate	resolution	for	circular	well as	primary	Aggregate one to one	Integers,	polymorphic  one to one	using	/	  object level  compliant compliant	tables for loss of	/ byte	runtime	Query	for primary	ternary	multiple	classes to private	through
						Version	fee	available  GUI	  classes	building  independence  EJB support	objects	grouping  functions	of queries	objects	identities objects	keys	mappings  associations Dates, etc.  queries	associations  outer joins versioning transactions  API	API	 metadata	transactions  processing  reflection Caching key generation associations tables	one table  fields	accessors
						1	  2	  3	  4		5		6	 7		8		9		10	11		12		13	 14	 15	16	17	18		19		20		21		22	  23	 24		25	26	  27	 28		29	  30	 31	32		33		34	 35	 36		37

 Abra				0		0.9.6	Yes	Yes	No		No		No	JDBC *	No  *	Yes	 No	No		Yes *	Yes *	Yes	Yes *	No  *	No  *	Yes	 No  *	Yes *	Yes		No	Yes	Yes		No	No	No	Yes		Yes	 No	Yes *	Yes		?		No  *	Yes *	No		Yes *				
 BasicWebLib					0.7i	Yes	Yes	No		No		Yes *			?	*	Yes	Yes	Yes		No		No	No	No	Yes	Yes	Yes	Yes	Yes	Yes		Yes	No	No		No	No	No	No		No	 No	 No	Yes		?		No	 ?	?		?		
 Castor						0.9.5	Yes	Yes	No		Yes *	 No	JDBC *	No  *	Yes	 No	No		Yes *	Yes	?	No	Yes	Yes *	Yes	Yes	 No		Yes		Yes	Yes *	Yes		No	Yes	No	 ?		No	 Yes	Yes *	Yes *	  ?		Yes *	No	 No		Yes					
 CayenneFramework				1.1	Yes	Yes	Yes	No		No	JDBC *	Yes  *	Yes	Yes	Yes		Yes *	Yes *	Yes	Yes	Yes	?	 Yes *	?		?		Yes		No  *	Yes *	?		No	No	Yes *	?		?		?	 ?	?		?		?	  ?	?		?				
 CocoBase					4	No	No	Yes	Yes		No	JDBC *	Yes *	Yes	 ?	Yes		Yes	?	?	Yes	Yes	Yes	Yes	Yes	Yes	Yes		Yes *	Yes	Yes		No	No	No	?		No	Yes	Yes *	?		?		?	  ?	  ?		?						
 DataBind					0.4	Yes	Yes	No		Yes		Yes *	JDBC *			No	Yes	Yes		No		No	 No	No	Yes	No	No		No		?		?		No	No	No		No	No	 ?	No		No	  Yes	No	?		?		?	?	?		?
 EdgeXtend					2	*	No	No	Yes	No  *	No	ODBC *	Yes *	Yes	No  *	No  *	Yes *	Yes	Yes	Yes	Yes	Yes	Yes *	No  *	Yes	Yes		Yes	Yes	Yes		No  *	No	No	Yes		Yes	No	No  *	Yes		No		?	  Yes *	?		?							
 EnterpriseObjectsFramework			?	No  *	No	Yes	No		No	JDBC *	No  *	Yes	 No  *	No  *	Yes *	Yes *	Yes	Yes	Yes	Yes *	Yes	?		Yes *	No  *	Yes	Yes *	Yes		No	No	Yes *	?		No	Yes *	Yes *	Yes *	  ?		Yes *	Yes	?		?										
 Expresso					?	Yes	Yes	No		No		No	JDBC *	Yes *	Yes	Yes	Yes		?		?	?	Yes	Yes	Yes	Yes	  ?		?		?		?		?	Yes		No	No	No	No  *	No	?	?	?		?		?	  ?	  ?		?		
 FireStorm						No  *																																																	
 FrontierSuite for J2EE & J2SE			3.1	No	No	Yes	Yes		No	JDBC *	Yes *	Yes	 No	Yes		Yes	Yes	Yes	Yes *	Yes	Yes	Yes	Yes	Yes *	Yes		Yes	Yes	Yes		No	No	No	Yes *	Yes	Yes	Yes	Yes		No		Yes	?	?		?									
 FrontierSuite for JDO				3.0 SP1	No	No	Yes	Yes		No	JDBC *	Yes *	Yes	No	No  *	Yes *	Yes	Yes	Yes *	Yes	Yes	Yes	Yes	Yes *	Yes		Yes	Yes	Yes		Yes	No	No	Yes *	Yes	Yes	Yes	Yes		No		Yes	?	?		?									
 Hibernate					3.0.2	Yes	Yes	No  *	Yes		No	JDBC *	Yes *	Yes	Yes	Yes		Yes *	Yes *	Yes	Yes *	Yes *	Yes	Yes	Yes *	Yes *	Yes *	Yes *	Yes *	Yes		No	Yes *	No  *	Yes *	Yes *	No  *	Yes *	Yes *	Yes *	Yes (3)	Yes	Yes		Yes										
 iBATIS DB Layer				2	Yes	Yes	No  *	Yes *	Yes *	JDBC *	Yes *	Yes	Yes *	Yes *	Yes *	No	No	 No	Yes *	Yes *	Yes	Yes	No		Yes		Yes	No	 No  *	 No  *	No	No	 No		No  *	Yes	Yes *	Yes *	  ?		Yes *	Yes	?		Yes										
 Infobjects ObjectDRIVER			Yes	No	 No	 No		Yes		No	ODBC *	No  *	  Yes	 No	Yes		Yes	  Yes	Yes	Yes	Yes	Yes	Yes	  Yes	  Yes	  Yes		No	  Yes	Yes		No  *	Yes	 No	 Yes		No	  No	 Yes	Yes		Yes	  Yes	?	  ?		?								
 InterSystems Cache				5.0RC3								 JDBC *	Yes *	Yes *	?	Yes *	 ?		?	  ?	Yes *	Yes *	?	 ?		?		?		?		?		?	  ?						?					?	?		?		?	  ?	  ?		?
 Jakarta ObjectRelationalBridge			1	Yes	Yes	Yes *	Yes		No	JDBC *	Yes *	Yes	Yes	Yes		Yes *	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes		Yes	 Yes *	Yes		Yes *	Yes *	No  *	Yes		No  *	No  *	Yes *	Yes *	Yes	Yes	Yes	Yes		Yes				
 Java Ultra-Lite Persistence (JULP)		1.0.1	yes		Yes	Yes	No		Yes	Yes		Yes		Yes	Yes	Yes		No		?	No	Yes	Yes *	Yes	?		Yes	Yes	Yes		Yes	Yes *	No		No	No	No	No		Yes	Yes	Yes	?		Yes	  ?	Yes	Yes	
 JaxorFramework					2.2	Yes	Yes	No		No  *	No	JDBC *	Yes *	Yes	Yes	?		Yes *	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes		Yes *	Yes *	Yes *	 ?	 ?		No	Yes		Yes	No	Yes *	?		?		?	  ?	  ?		?
 JdoGenie					1.3.2	No  *	No	Yes	Yes		No	JDBC *	Yes *	Yes	No	No		Yes *	Yes	Yes	Yes *	Yes	Yes *	Yes	Yes	Yes	Yes		Yes *	Yes *	Yes		Yes	No	Yes *	Yes *	Yes *	No	Yes *	Yes		?		?	  ?	  ?		?	
 JdoMax						1.0	Yes	No	No	Yes	No	yes	No	Yes	No	Yes	Yes	Yes	Yes	Yes	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	Yes	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	Yes	yes	yes																																																	
 JDX						4.5	No	No	Yes	Yes		No	JDBC *	Yes *	Yes	 No  *	Yes		Yes	Yes *	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes		No  *	Yes	No  *	No	No	No  *	Yes *	No	Yes	No	Yes		Yes	Yes	?	  ?		?		
 Lychee						0.01	Yes	Yes	No	Yes	No	JDBC	No	Yes	Yes	No	Yes	No	No	Yes	No	Yes	Yes	No	No	Yes	Yes	No	JDBC	No	No	No	Yes	No	No	No	Yes	Yes	Yes	Yes	Yes	No	Yes	Yes		Yes		 
 KodoJdo					3.3.3	No  *	No	Yes *	Yes		No	JDBC *	Yes *	Yes	Yes	Yes		Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes		Yes	Yes *	Yes		Yes	No	No	Yes		Yes	No	Yes	Yes		?		Yes	Yes	Yes		?
 Signsoft intelliBO				3.6	No  *	No	Yes	Yes		No	JDBC *	Yes *	Yes	No	No  *	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes		Yes	 Yes	Yes		Yes	No	No	Yes *	Yes	No	Yes *	Yes		No  *	Yes	Yes	Yes		No				
 SimpleOrm					0.1	Yes *	Yes *	No  *	No  *	No  *	JDBC *		*	Yes *	Yes *	Yes *	Yes *	Yes *	Yes	Yes *	Yes	No  *	No  *	Yes *		*	Yes *	 No  *	Yes *	Yes		No  *	No  *	No  *	No  *	No	No  *	Yes *	Yes *	Yes *	No	 ?	  ?		?				
 The ProductivityEnvironmentForJava (PE:J)	2.2.2	Yes *	No	Yes	Yes		No	JDBC *	Yes *	Yes	Yes	Yes		Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes		No  *	Yes	Yes		Yes	No	Yes *	Yes		Yes *	No	Yes	Yes		Yes	Yes	?	  ?		?					
 TopLink					9.03	No  *	No  *	Yes	Yes		No  *	JDBC *	Yes *	Yes	Yes	Yes		Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes		Yes *	Yes *	Yes		No  *	No	No	Yes *	 No	Yes	Yes *	Yes *	Yes	Yes	?	  Yes		Yes			
 VBSF						3.03	No	 No	Yes	Yes		No	JDBC *	Yes *	Yes	Yes *	Yes		Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes		No	Yes	Yes		Yes *	Yes *	No	Yes *	 No	Yes	Yes	Yes		Yes	  Yes	?	  ?		?	
 XIC                                            4.2     No	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	

''' 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., A''''''ddressFinder.findById(1) == A''''''ddressFinder.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. DomainObject''''''s 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 = A''''''ddressFinder.selectByPrimaryKey(new Long(1));

assertTrue(address == A''''''ddressFinder.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)'''
	* Abra: 0.9.6
	* BasicWebLib - 0.7i
	* DB Visual Architect - 1.0
	* Castor: 0.9.5
	* CayenneFramework: 1.1
	* CocoBase: 4.0
	* DataBind: 0.4
	* EdgeXtend: 2.0 (Java, 8.0 C++ pending)
	* EnterpriseObjectsFramework: 5.2 (same as WebObjects)
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: 3.0
	* FrontierSuite for JDO: 3.0 SP1
	* Hibernate: 2.1
	* Hydrate 2.0beta1
	* iBATIS DB Layer - 2.0 
	* Infobjects ObjectDRIVER: Yes
	* InterSystems Cache - 5.0RC3
	* Jakarta ObjectRelationalBridge: 1.0
	* Java Ultra-Lite Persistence (JULP): 1.0.1
	* JaxorFramework: 2.2
	* JdoGenie: 1.3.2
	* JDX: 4.5
	* KodoJdo: 3.3.0
	* LiDO: See XIC
	* Lychee: 0.01
	* O/R Broker: v2.0
	* PowerMapJdo: 1.4
	* Signsoft intelliBO: 3.6
	* SimpleOrm: 0.10
	* The ProductivityEnvironmentForJava (PE:J): 2.2.2
	* TopLink: 9.03
	* VBSF: 3.03
	* XIC:  4.2

'''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'''
	* Abra: Yes
	* BasicWebLib: Yes
	* Castor: Yes
	* CayenneFramework: Yes
	* CocoBase: No
	* DataBind: Yes
	* DB Visual Architect: No
	* EdgeXtend: No
	* EnterpriseObjectsFramework: No
	* Expresso: Yes
	* FrontierSuite for J2EE & J2SE: No
	* FrontierSuite for JDO: No
	* Hibernate: Yes 
	* Hydrate: Yes
	* iBATIS DB Layer: Yes
	* Infobjects ObjectDRIVER: No
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): Yes
	* JaxorFramework: Yes
	* JdoGenie: No
	* JDX: No
	* KodoJdo: No
	* LiDO: See XIC
	* Lychee: Yes
	* O/R Broker: Yes
	* PowerMapJdo: Extensibility interfaces
	* Signsoft intelliBO: No
	* SimpleOrm: Source available. And it is simple enough to follow easily.
	* Sql2java: Yes
	* The ProductivityEnvironmentForJava (PE:J): No 
	* TopLink: No, but portions of TopLink source code is included if the customer wishes to make some modification/extensions to TopLink.
	* VBSF: No
	* XIC: No

'''4. Has mapping GUI '''
	* Abra: No	
	* BasicWebLib - NO	
	* DB Visual Architect - Yes
	* Castor: No	
	* CayenneFramework: Yes, and a very advanced one	
	* CocoBase: Yes	
	* DataBind: No	
	* EdgeXtend: Yes	
	* EnterpriseObjectsFramework: Yes	
	* Exadel offers a low-cost GUI Eclipse plugin: http://www.exadel.com/products_ORMstudio.htm	
	* Expresso: No	
	* FrontierSuite for J2EE & J2SE: Yes	
	* FrontierSuite for JDO: Yes	
	* Hibernate: No - see our FAQ for why it would be unnecessary / undesirable http://hibernate.org/16.html#A8
	* Hydrate - Yes, simple for visualization and query mapping
	* iBATIS DB Layer - NO (DBVisualizer eliminates any desire for one)	
	* Infobjects ObjectDRIVER: No	
	* InterSystems Cache: ?	
	* Jakarta ObjectRelationalBridge: Yes (work in progress)
	* Java Ultra-Lite Persistence (JULP): yes
	* JaxorFramework: No
	* JdoGenie: Yes
	* JDX - Yes
	* KodoJdo: Yes (also includes integration with JBuilder, WSAD/Eclipse, Sun ONE Studio/Netbeans)
	* LiDO: See XIC
	* Lychee: No
	* O/R Broker: No yet.
	* PowerMapJdo: Advanced GUI
	* Signsoft intelliBO: Yes
	* SimpleOrm: No, not really necessary as nothing is generated.
	* SpadeSoft XJDO: Yes (with integrated as an Eclipse/WSAD plugin)
	* Sql2java: No, no need of GUI everything is automatic !
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes

'''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'''
	* Abra: No
	* BasicWebLib - YES (SQL is coded)
	* Castor: No
	* CayenneFramework: No
	* CocoBase: No
	* DataBind: Yes (No for where clauses)
	* DB Visual Architect No
	* EdgeXtend: No
	* EnterpriseObjectsFramework: No
	* Expresso: No
	* FrontierSuite for J2EE & J2SE: No
	* FrontierSuite for JDO: No
	* Hibernate: No
	* Hydrate: No, but permits any SQL to be mapped into any number of objects
	* iBATIS DB Layer - YES, you have the full power of SQL at your fingertips
	* Infobjects ObjectDRIVER: No
	* Jakarta ObjectRelationalBridge: No
	* Java Ultra-Lite Persistence (JULP): yes(only SELECT)
	* JaxorFramework: No
	* JdoGenie: No
	* JDX - No
	* KodoJdo: No
	* LiDO: See XIC
	* Lychee: No
	* O/R Broker: Yes, intentionally
	* PowerMapJdo: Fully dynamic
	* Signsoft intelliBO: No
	* SimpleOrm: No. But it allows manual SQL when you need it which can be ''much'' faster.
	* SpadeSoft XJDO: No
	* Sql2java: No
	* The ProductivityEnvironmentForJava (PE:J): No
	* TopLink: No (but if you have any favourite 'custom' SQL, that's O.K., too!)
	* VBSF: No
	* XIC: No

 
'''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 SessionBean''''''s and BMP EntityBean''''''s, 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 SessionBean''''''s, 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'''
	* Abra: Yes
	* BasicWebLib - YES
	* Castor: Yes
	* CayenneFramework: Yes
	* CocoBase: Yes
	* DataBind: No
	* DB Visual Architect: Yes
	* EdgeXtend: Yes
	* EnterpriseObjectsFramework: Yes
	* Expresso: Yes
	* FrontierSuite for J2EE & J2SE: Yes 
	* FrontierSuite for JDO: Yes 
	* Hibernate: Yes 
	* Hydrate: Yes
	* iBATIS DB Layer - YES
	* Infobjects ObjectDRIVER: Yes
	* InterSystems Cache: Yes, as collections, parent/child, and M:N
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): yes
	* JaxorFramework: Yes
	* JdoGenie: Yes
	* JDX: Yes
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: Yes, all kinds of relationships supported.
	* O/R Broker: Yes
	* PowerMapJdo: Yes, advanced plurality features
	* Signsoft intelliBO: Yes
	* SimpleOrm: Yes, and also identifying foreign keys.
	* SpadeSoft XJDO: Yes
	* Sql2java: Yes
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes

'''10. Mapping supports grouping (GROUP BY clause) '''
	* Abra: No
	* BasicWebLib: Yes
	* Castor: No
	* CayenneFramework: Yes
	* CocoBase: ?
	* DataBind: Yes
	* DB Visual Architect : Yes
	* EdgeXtend: No, but provides efficient developer extensions
	* EnterpriseObjectsFramework: Yes, with opensource additional qualifiers
	* Expresso: Yes
	* FrontierSuite for J2EE & J2SE: No 
	* FrontierSuite for JDO: No 
	* Hibernate: Yes 
	* Hydrate: Yes
	* iBATIS DB Layer - YES (Full SQL functionality available)
	* Infobjects ObjectDRIVER: No
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): yes
	* JaxorFramework: Yes
	* JdoGenie: No
	* JDX: No, but supported through pass-thru SQL mechanism
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: Yes, full SQL support available.
	* O/R Broker: Yes
	* PowerMapJdo: Preview
	* Signsoft intelliBO: No
	* SimpleOrm: Using Views, but this is not what SimpleOrm is about.
	* SpadeSoft XJDO: Yes
	* Sql2java: No
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes
	* VBSF: Yes, via Named SQL Commands
	* XIC: No
 
'''11. Mapping supports aggregate functions (count(), avg(), etc.) '''
	* Abra: No
	* BasicWebLib - YES
	* Castor: No
	* CayenneFramework: Yes
	* CocoBase: Yes
	* DataBind: Yes
	* DB Visual Architect: Yes
	* EdgeXtend: No, but provides efficient developer extensions
	* EnterpriseObjectsFramework: No, but there are ways around
	* Expresso: Yes
	* FrontierSuite for J2EE & J2SE: Yes 
	* FrontierSuite for JDO: No (Being released as an extension shortly)
	* Hibernate: Yes 
	* Hydrate: Yes
	* iBATIS DB Layer - YES (Full SQL functionality available)
	* Infobjects ObjectDRIVER: Yes
	* InterSystems Cache: Can define calculated "fields" or "properties" using Cache Object script, visual basic, and soon Java.
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): yes
	* JaxorFramework: ?
	* JdoGenie: No
	* JDX: Yes
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: No (planned feature)
	* O/R Broker: Yes
	* PowerMapJdo: Preview
	* Signsoft intelliBO: No (but special queries for such operations)
	* SimpleOrm: Using Views, but this is not what SimpleOrm is about.
	* SpadeSoft XJDO: Yes
	* Sql2java: No
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes
 
'''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()")
	* Abra: Yes
	* BasicWebLib: No
	* Castor: ?
	* CayenneFramework: Yes
	* CocoBase: ?
	* DataBind: No
	* EdgeXtend: Yes
	* EnterpriseObjectsFramework: Yes
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: Yes 
	* FrontierSuite for JDO: Yes 
	* Hibernate: some proxy issues
	* Hydrate: Yes
	* iBATIS DB Layer: No
	* Infobjects ObjectDRIVER: Yes
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): no
	* JaxorFramework: Yes
	* JdoGenie: Yes
	* JDX: Yes
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: No
	* O/R Broker: Yes, within Query or Transaction session.
	* PowerMapJdo: Yes
	* Signsoft intelliBO: Yes
	* SimpleOrm: Yes.
	* SpadeSoft XJDO: Yes
	* Sql2java: No 
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes

'''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. DomainObject''''''s 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'''
	* Abra: No (but simple objects (like Amount[code,value] can be inlined in the container object)
	* BasicWebLib: Yes
	* Castor: Yes (but limited)
	* CayenneFramework: ?
	* CocoBase: Yes
	* DataBind: No
	* EdgeXtend: Yes
	* EnterpriseObjectsFramework: There are ways to do this.
	* Expresso: Yes
	* FrontierSuite for J2EE & J2SE: Yes 
	* FrontierSuite for JDO: Yes 
	* Hibernate: Yes
	* Hydrate: read, yes. Write, no.
	* iBATIS DB Layer - YES (just add additional mutators/accessors to your JavaBean)
	* Infobjects ObjectDRIVER: Yes
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes.
	* Java Ultra-Lite Persistence (JULP): yes (with some coding)
	* JaxorFramework: Yes
	* JdoGenie: There are ways to do this.
	* JDX: Yes
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: Yes
	* O/R Broker: Yes
	* PowerMapJdo: Yes, full support
	* Signsoft intelliBO: Yes
	* SimpleOrm: No, not simple to write back.
	* SpadeSoft XJDO: Yes 
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes
 
'''18. Supports both many to many and one to many associations'''
	* Abra: Yes
	* BasicWebLib: Yes
	* Castor: Yes
	* CayenneFramework: Yes
	* CocoBase: Yes
	* DataBind: No
	* EdgeXtend: Yes for one-to-many, many-to-many requires a workaround
	* EnterpriseObjectsFramework: Yes
	* Expresso: Yes
	* FrontierSuite for J2EE & J2SE: Yes 
	* FrontierSuite for JDO: Yes
	* Hibernate: Yes
	* Hydrate: Yes
	* iBATIS DB Layer: Yes
	* 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: Yes, supports all kinds of relationships.
	* O/R Broker: Yes
	* PowerMapJdo: Yes
	* Signsoft intelliBO: Yes
	* SimpleOrm: One to Many. Are many to many really useful in practice?
	* SpadeSoft XJDO: Yes 
	* Sql2java: Yes
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes
 
'''19. Supports collections of Strings, Integers, Dates, etc'''
	* Abra: (Developer coding is needed)
	* BasicWebLib: Yes
	* Castor: Yes
	* CayenneFramework: Yes, there is something called DataRows in Cayenne which are untyped maps.
	* CocoBase: Yes
	* DataBind: No
	* EdgeXtend: No, but provides efficient developer extensions
	* EnterpriseObjectsFramework: ?
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: Yes 
	* FrontierSuite for JDO: Yes 
	* Hibernate: Yes (as an actual table association, NOT as a serialized blob)
	* Hydrate: only as referenced objects.
	* iBATIS DB Layer: Yes
	* Infobjects ObjectDRIVER: Yes
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): ?
	* JaxorFramework: Yes
	* JdoGenie: Yes
	* JDX: Yes
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: No
	* O/R Broker: Yes
	* PowerMapJdo: Yes, full control of Item Mapping within plurality
	* Signsoft intelliBO: Yes
	* SimpleOrm: Yes, as relationships.
	* SpadeSoft XJDO: Yes 
	* Sql2java: Yes
	* The ProductivityEnvironmentForJava (PE:J): Yes 
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes
 
'''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'''
	* Abra: Yes
	* BasicWebLib - YES
	* Castor: Yes
	* CayenneFramework: Yes
	* CocoBase: Yes
	* DataBind: ?
	* EdgeXtend: Yes
	* EnterpriseObjectsFramework: Only with propagated primary keys, otherwise no.
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: Yes
	* FrontierSuite for JDO: Yes
	* Hibernate: Yes (on primary key or arbitrary foreign key)
	* Hydrate: Yes
	* iBATIS DB Layer: Yes
	* 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: Yes, supports all kinds of relationships.
	* O/R Broker: Yes
	* PowerMapJdo: Yes
	* Signsoft intelliBO: Yes
	* SimpleOrm: Yes, as a special case of one to many.
	* SpadeSoft XJDO: Yes 
	* Sql2java: Yes
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes
 
'''22. Can fetch associated objects using SQL outer joins'''
	* Abra: No
	* BasicWebLib: Yes
	* Castor: Yes
	* CayenneFramework: No (planned feature)
	* CocoBase: Yes (via manual SQL tweaking)
	* DataBind: No
	* EdgeXtend: Yes
	* EnterpriseObjectsFramework: Yes
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: Yes
	* FrontierSuite for JDO: Yes
	* Hibernate: Yes (ANSI and Oracle style outerjoins)
	* Hydrate: that's not the half of it.
	* iBATIS DB Layer: Yes
	* Infobjects ObjectDRIVER: No
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): yes
	* JaxorFramework: Yes (Implemented in 2.3, as well as simple joins)
	* JdoGenie: Yes (also inner joins to traverse many tables)
	* JDX: No (But can fetch associated objects using minimum number of database calls)
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: Yes
	* O/R Broker: Yes
	* PowerMapJdo: Yes
	* Signsoft intelliBO: Yes
	* SimpleOrm: Not yet, but the API is designed for it.
	* SpadeSoft XJDO: Yes 
	* Sql2java: Yes
	* The ProductivityEnvironmentForJava (PE:J): No (in the next version)
	* TopLink: Yes (manually specified by using the Expression.anyOfAllowingNone() method)
	* VBSF: No
	* XIC: Yes
 
'''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 
	* Sql2java: Yes
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes

'''25. Providing a SUN JDO compliant API'''
	* Abra: No
	* BasicWebLib - NO
	* Castor: No
	* CayenneFramework: No
	* CocoBase: No
	* DataBind: No
	* EdgeXtend: No, but provides lightweight Java mapping
	* EnterpriseObjectsFramework: No
	* Expresso: No
	* FrontierSuite for J2EE & J2SE: No
	* FrontierSuite for JDO: Yes
	* Hibernate: No
	* Hydrate: No
	* iBATIS DB Layer - NO (way!)
	* Infobjects ObjectDRIVER: Soon
	* Jakarta ObjectRelationalBridge: Yes, currently as a plugin to the JDO RI
	* Java Ultra-Lite Persistence (JULP): no
	* JaxorFramework: ?
	* JdoGenie: Yes
	* JDX: No
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: No
	* O/R Broker: No.
	* PowerMapJdo: Yes
	* Signsoft intelliBO: Yes
	* SimpleOrm: No, not simple!
	* SpadeSoft XJDO: Yes 
	* Sql2java: No
	* The ProductivityEnvironmentForJava (PE:J): Yes 
	* TopLink: Symbolic in latest TopLink 903. Not fully transparent (No byte-code enhancer).
	* VBSF: Yes (JDO API supported, no JDO Query language, no class post-processing required)
	* XIC: Yes
 
'''26. Providing an ODMG compliant API'''
	* Abra: No
	* BasicWebLib - NO
	* Castor: Yes
	* CayenneFramework: No
	* CocoBase: No
	* DataBind: No
	* EdgeXtend: No
	* EnterpriseObjectsFramework: No
	* Expresso: No
	* FrontierSuite for J2EE & J2SE: No
	* FrontierSuite for JDO: No
	* Hibernate: No (ODMG support has been removed)
	* Hydrate: No
	* iBATIS DB Layer: NO
	* Infobjects ObjectDRIVER: yes
	* Jakarta ObjectRelationalBridge: Yes, (OQL not completely implemented)
	* Java Ultra-Lite Persistence (JULP): no
	* JaxorFramework: ?
	* JdoGenie: No
	* JDX: No
	* KodoJdo: No
	* LiDO: See XIC
	* Lychee: No
	* O/R Broker: No
	* PowerMapJdo: Provides JDO api
	* Signsoft intelliBO: No
	* SimpleOrm: No, not simple.
	* SpadeSoft XJDO: No
	* Sql2java: No
	* The ProductivityEnvironmentForJava (PE:J): No
	* TopLink: No
	* VBSF: Partial
	* XIC: Yes
 
'''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'''
	* Abra: No
	* BasicWebLib - NO
	* Castor: Yes
	* CayenneFramework: No
	* CocoBase: yes
	* DataBind: Yes
	* EdgeXtend: No
	* EnterpriseObjectsFramework: Yes, in practice, if not necessarily in theory. 
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: Yes
	* FrontierSuite for JDO: Yes
	* Hibernate: No. (well, only for object instantiation)
	* Hydrate: No.
	* iBATIS DB Layer: Yes
	* Infobjects ObjectDRIVER: No
	* Jakarta ObjectRelationalBridge: No (user can choose different property access strategies)
	* Java Ultra-Lite Persistence (JULP): yes
	* JaxorFramework: No
	* JdoGenie: No
	* JDX: Yes
	* KodoJdo: No
	* LiDO: See XIC
	* Lychee: No
	* O/R Broker: Yes
	* PowerMapJdo: No
	* Signsoft intelliBO: No
	* SimpleOrm: No! You can structure your code the way you want to, no tricks.
	* SpadeSoft XJDO: No 
	* Sql2java: No ! It generates only code, so you can see what you really use !
	* The ProductivityEnvironmentForJava (PE:J): No 
	* TopLink: Yes
	* VBSF: Yes
	* XIC: No
 
'''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 = A''''''ddressFinder.selectByPrimaryKey(new Long(1));

assertTrue(address == A''''''ddressFinder.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.

	* Abra: ?
	* BasicWebLib - ?
	* Castor: ?
	* CayenneFramework: ?
	* CocoBase: ?
	* DataBind: ?
	* EdgeXtend: No
	* EnterpriseObjectsFramework: Yes
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: No
	* FrontierSuite for JDO: No
	* Hibernate: Yes (and quaternary, etc).
	* Hydrate: Yes, and n-ternary.
	* iBATIS DB Layer - ?
	* Infobjects ObjectDRIVER: Yes
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes ( ? )
	* Java Ultra-Lite Persistence (JULP): ?
	* JaxorFramework: ?
	* JdoGenie: ?
	* JDX: Yes
	* KodoJdo: ?
	* LiDO: See XIC
	* Lychee: Yes
	* O/R Broker: Yes.
	* PowerMapJdo: Yes, most supported
	* Signsoft intelliBO: Not yet
	* SimpleOrm: Yes, but just as objects!
	* SpadeSoft XJDO: ?
	* Sql2java: No
	* The ProductivityEnvironmentForJava (PE:J): Yes
	* TopLink: Yes ( ? ) 
	* VBSF: Yes
	* XIC: Yes

'''34. Supports mapping of one class to multiple tables'''
	* Abra: We agree this is a bad thing and do not support it.
	* BasicWebLib - NO
	* Castor: Yes (via extends relationship)
	* CayenneFramework: Yes
	* CocoBase: ?
	* DataBind: ?
	* EdgeXtend: ?
	* EnterpriseObjectsFramework: Yes, through 'flattened' attributes and relationships
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: Yes
	* FrontierSuite for JDO: Yes
	* Hibernate: Yes (Hibernate3)
	* Hydrate: Yes, for read. Manual coding for write.
	* iBATIS DB Layer - YES (the best support for badly designed databases beyond your control!)
	* Infobjects ObjectDRIVER: Yes
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): yes
	* JaxorFramework: ?
	* JdoGenie: ?
	* JDX: Yes
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: Yes, full support for joins.
	* O/R Broker: Yes.
	* PowerMapJdo: Yes. Full support for Joined, Unioned and hybrid structures
	* Signsoft intelliBO: Yes
	* SimpleOrm: No
	* SpadeSoft XJDO: Yes (depending on context)
	* Sql2java: No
	* The ProductivityEnvironmentForJava (PE:J): Yes 
	* TopLink: Yes
	* VBSF: Yes
	* XIC: Yes

	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'''
	* Abra: Yes - fields in a class which are also classes can be 'inlined' - storing the fields in the parent's table.
	* BasicWebLib - ?
	* Castor: No
	* CayenneFramework: Yes
	* CocoBase: ?
	* DataBind: ?
	* EdgeXtend: Yes (8.0 C++ and soon in Java)
	* EnterpriseObjectsFramework: Yes
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: ?
	* FrontierSuite for JDO: ?
	* Hibernate: Yes
	* Hydrate: Yes for read. Manual coding for write.
	* iBATIS DB Layer - YES 
	* Infobjects ObjectDRIVER: ?
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): yes
	* JaxorFramework: ?
	* JdoGenie: ?
	* JDX: Yes
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: Yes, any number of classes to one table.
	* O/R Broker: Yes
	* PowerMapJdo: Yes, full support.
	* Signsoft intelliBO: Yes
	* SimpleOrm: ?
	* SpadeSoft XJDO: Yes 
	* Sql2java: No
	* The ProductivityEnvironmentForJava (PE:J): ?
	* TopLink: ?
	* VBSF: ?
	* XIC: Yes

'''36. Supports persistence of properties through private fields'''
	* Abra: No
	* BasicWebLib: ?
	* Castor: No
	* CayenneFramework: No
	* CocoBase: ?
	* DataBind: ?
	* EdgeXtend: ?
	* EnterpriseObjectsFramework: No
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: ?
	* FrontierSuite for JDO: ?
	* Hibernate: Yes
	* Hydrate: No, beans only.
	* iBATIS DB Layer: NO (bad practice?)
	* Infobjects ObjectDRIVER: ?
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): ?
	* JaxorFramework: ?
	* JdoGenie: ?
	* JDX: Yes
	* KodoJdo: Yes
	* LiDO: See XIC
	* Lychee: Yes
	* O/R Broker: Yes, if SecurityManager allows it.
	* PowerMapJdo: Yes.
	* Signsoft intelliBO: Yes
	* SimpleOrm: ?
	* SpadeSoft XJDO: Yes 
	* Sql2java: Yes
	* The ProductivityEnvironmentForJava (PE:J): ?
	* TopLink: Yes
	* VBSF: ?
	* XIC: Yes

'''37. Supports persistence of properties through accessors (get/set methods)'''
	* Abra: Access is only through get-set - but not auto-persisted - need to call 'store' on the object to persist changed fields.
	* BasicWebLib: ?
	* Castor: Yes
	* CayenneFramework: Yes
	* CocoBase: ?
	* DataBind: ?
	* EdgeXtend: ?
	* EnterpriseObjectsFramework: Yes
	* Expresso: ?
	* FrontierSuite for J2EE & J2SE: ?
	* FrontierSuite for JDO: ?
	* Hibernate: Yes
	* Hydrate: Yes
	* iBATIS DB Layer: YES
	* Infobjects ObjectDRIVER: ?
	* InterSystems Cache: ?
	* Jakarta ObjectRelationalBridge: Yes
	* Java Ultra-Lite Persistence (JULP): yes
	* JaxorFramework: ?
	* JdoGenie: ?
	* JDX: Yes
	* KodoJdo: ?
	* LiDO: See XIC
	* Lychee: No, no need.
	* O/R Broker: Yes, and through constructor and multi-argument methods.
	* PowerMapJdo: Not needed with JDO
	* Signsoft intelliBO: No
	* SimpleOrm: ?
	* SpadeSoft XJDO: No need
	* Sql2java: Yes
	* The ProductivityEnvironmentForJava (PE:J): ?
	* TopLink: Yes
	* VBSF: ?
	* XIC: Yes, through persistent interface support

'''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 ? '''
	* CayenneFramework: Yes (via log4j you can log anywhere, even email the logs)
	* EnterpriseObjectsFramework: Yes
	* Hibernate: yes
	* Hydrate: yes
	* JDX: Yes
	* KodoJdo: Yes
	* Lychee: Yes, including timing information.
	* O/R Broker: Yes.
	* PowerMapJdo: Yes
	* SpadeSoft XJDO: Yes 
	* Sql2java: Yes
	* XIC: Yes

'''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?'''
	* EnterpriseObjectsFramework: Yes
	* O/R Broker: Yes
	* SpadeSoft XJDO: Yes (on all database platforms, regardless of database support)
	* XIC: Yes

'''43. Supports mapping of immutable objects?'''
	* KodoJdo: Yes
	* O/R Broker: Yes
	* XIC: Yes
----
See also FavoriteObjectRelationalTools