DataNucleus Usage

DataNucleus is Open Source, meaning that you have full access to the source code for all versions of DataNucleus. With this you have the capability to correct any errors that you encounter, but also better understand the data management process, and you can potentially extend DataNucleus to suit your needs.

DataNucleus is free. Our license is the Apache 2 License, providing the code and executables (JARs) free of charge. You are free to use DataNucleus in your projects. Please refer to the license for the precise wording. DataNucleus will always remain Open Source. Our license (Apache 2) is very flexible, much more than the license used for some other notable object/relational mapping software which use licenses like the LGPL.

DataNucleus is independent and unstoppable. The source code is open, and is not owned exclusively by some company. As such it cannot be bought by a large organisation such as Versant or Oracle and the product terminated (as has happened to customers of Kodo, JDO Genie over the last few years). Do you want that to happen to you? FYI EclipseLink is Oracle-driven and Hibernate is RedHat-driven. For the record OpenJPA was IBM-driven but they stopped development of it in 2014, and it has not changed significantly since.

DataNucleus is standards driven and standards compliant implementing all JDO and JPA specifications, providing all mandatory items and the majority of optional items as well as providing several value-added extensions. Standards compliance safeguards your applications future allowing you to swap between implementations. The likes of Kundera claim to be "standards compliant" yet don’t implement significant features (like supporting XML input for JPA), so using that will result in zero portability.

DataNucleus supports data management for many different types of datastores. These include the vast majority of RDBMS databases on the market today, MongoDB document store, Neo4j graph store, LDAP and other datastores meaning that if you change your datastore in the future you don’t need to change your data access layer.

DataNucleus provides outstanding performance when compared with the competing technologies.

DataNucleus does not bring in large numbers of dependencies unlike other persistence frameworks (for example, Hibernate) that have to provide a zip file just to package all of their requirements up. In fact DataNucleus could be run with just 1 third-party library (javax.jdo.jar when using JDO, or javax.persistence.jar when using JPA) - beat that!

DataNucleus is quality-driven being developed using a Test Driven Development methodology. We have more than 2000 unit tests that are run before any release guaranteeing a stable product. In addition we baseline our capabilities against standard Java TCKs (JDO, JPA) the definition of specification compliance. With our plugins you will not find large numbers of outstanding high priority issues that you have to workaround (unlike what you find in the Hibernate, OpenJPA, EclipseLink issue trackers for example).

DataNucleus provides a level of free support by way of Groups.IO or Gitter and also provides commercial support arrangements if you require it.

DataNucleus consulting can be arranged with the developers of DataNucleus.

DataNucleus is open to contributions/donations allowing individuals to help out and allowing companies to sponsor features that they require for their deployments of DataNucleus.

DataNucleus is plugin-driven using the OSGi standard mechanism, providing plugins to external caching software (Coherence, EHCache, etc), to external database-pooling software (DBCP, C3P0, etc), and much more.

Apache is a loose collection of projects with no general direction or collaboration so DataNucleus would simply be an independent part of an organisation there, hence no benefit.

DataNucleus infrastructure (website availability, support, issue tracking, nightly builds, release policy etc) is way in advance of anything that Apache has and moving there would be a step backwards in this respect. The Apache website is often unavailable, they only use mailing lists, they don’t have a general policy of providing nightly builds etc etc

Being part of Apache would not guarantee any more committers as demonstrated by many projects that have moved to Apache (and often ended up in the Apache 'attic').