There's many reasons customers choose CocoBase instead of Hibernate. Technically speaking, CocoBase is more suitable for enterprise applications. It includes features such as:
- Low level sql mapping and tuning, which allows to "fine tune" the SQL that the CocoBase runtime sends to the jdbc layer independently on per operation basis (select,insert,update,delete). It is possible, for instance, to introduce proprietary database optimization hints in the
low-level SQL maps
- Support for "any" inheritance strategy, which can be mixed across the class or interface hierarchy, as opposed to Hibernate, which only supports either single table or joined table inheritance across the entire hierarchy
- Support for "join" maps, that is, where one object maps to multiple tables
- Local or distributed relationship lazy-loading, which means that load "on-demand" of related objects also works in three-tier j2ee environments
- Local or distributed high-level scrollable cursor apis, which means that an open cursor can also be navigated in three-tier environment
- Support for centralized database repositories
- Support for query by example, and also low level (api based) and high level (declarative) OO querying - the high level query language is EJB-QL, a standard proposed as part of Sun's EJB specification, and not a "made-up" proprietary language
- Total independency between the object model and the OR mapping metadata, which means it supports relationship mapping on "custom" or legacy (eg. Vetor/Hashtable) collections, not only Java 2 collections
The above items are just to give you a few reasons why CocoBase is preferred against Hibernate. But we would also like to mention performance: as far as we know, CocoBase is the only O/R tool that can run faster than hand-coded JDBC (tests include jdk 1.3 or later). Just so you know, our core runtime code is specially design to take advantage of JIT
optimization techniques, which doesn't happen with hand-coded jdbc.
Besides, the CocoBase runtime performs linearly, as opposed to many other OR tools (Hibernate included), which makes it the most scalable runtime available. We have customers with very complex models (over 200 classes and 300 relationships) that load and manipulate object graphs with thousands of objects without additional performance penalties (last time we did scalability tests with Hibernate we noticed that the time taken by a session to update an object graph increases exponentially to the number of objects loaded by that session).
Let us remind you that the CocoBase code is very mature (it's been almost ten years since the first version). Also, CocoBase runtime is free to distribute to customers. Only develpment licenses are changed, but those include a one-year support contract, whereas with Hibernate, you would end up having to pay for support for more complex projects with strict deadlines.
We hope that helps give you a general idea of why one would choose CocoBase. If you need more information, please let us know.