ActiveObjects is an intuitive, pure-Java ORM. AO is designed from the ground up to be extremely simple and easy to use from an API standpoint. AO can be used with either an existing database schema, or it can auto-generate the database schema from the user-specified entity interfaces. ActiveObjects also supports Rails-style database migrations, allowing incremental changes and refactoring of the database schema without data loss.

ActiveObjects can be more performant than traditional, data mapper ORMs due to its natural use of lazy-loading coupled with sophisticated caching mechanisms. However, performance is not the primary design goal of the project. Rather, the intention is to create an ORM which is powerful and yet extremely natural to use and integrate into your project. This design has lead to certain performance benefits (such as lazy-loading), but on the whole, data mapper ORMs are inherantly slightly more performant than ActiveObjects can be just from a theoretical standpoint.


Preliminary releases (leading up to 1.0) will be made available on this site. These releases are for testing purposes only and should be considered to be unstable. Please report bugs using the issue tracker (requires a login). The current release is 0.8.2 released on April 22nd, 2008.


ActiveObjects is also available as a Maven2 package through the repository. To use ActiveObjects in your Maven2 project, add the following to your <dependencies> section:

Note that while ActiveObjects has support for a number of connection pools and databases, it does not require them as Maven2 dependencies. To use ActiveObjects with any database and pool provider, you must explicitly include the relevant dependency information in your project's pom.xml.


The javadoc is available here.

If you're new to ActiveObjects, I suggest you start with a simple example which shows many of the major concepts and features.

Alternatively, a number of examples and walk-throughs have been written on the Code Commit blog. All of them are available under the ActiveObjects tag. In this vein, an article has been published at Javalobby covering some of the basic design principles of the API.

If you're looking for a more "realistic" example, try checking out the dogfood blog module in the SVN (svn co This example is used for both testing, and development of new features as it allows the developers to "eat their own dogfood" so to speak, getting a clearer picture of how the API should be used. A second "dogfood test" has been created in the DogfoodContacts module, enabling similar tests from a different perspective.