Introducing EclipseLink from JavaLobby

The Eclipse Persistence Services Project, more commonly known as EclipseLink, is a comprehensive open source persistence solution. EclipseLink was started by a donation of the full source code and test suites of Oracle's TopLink product. This project brings the experience of over 12 years of commercial usage and feature development to the entire Java community. This evolution into an open source project is now complete and developers will soon have access to the EclipseLink 1.0 release.
We describe EclipseLink as a comprehensive solution because it delivers not one, but a set of persistence services enabling developers to efficiently develop applications that access data in a variety of data sources and formats. EclipseLink's services currently include object-relational with JPA, object-XML binding in MOXy (with support for JAXB), and a Service Data Objects (SDO) implementation sharing a common mapping core. EclipseLink’s most popular persistence service is dealing with relational databases through JPA. In this article I'll introduce the EclipseLink JPA implementation and some of its advanced features. We'll delve into the other persistence services in future articles.
JPA and Beyond
EclipseLink 1.0 supports JPA 1.0 and also offers many advanced features. The project's intent is to deliver a standards based solution focussed on JPA but with the abilitity to use advanced features for those applications where they are required. By focusing first on JPA, the EclipseLink project enables broad integration and minimizes coupling. With the recent announcement that EclipseLink will be delivering the reference implementation of JPA 2.0 (JSR 317) the project team will continue to lead the standardization of many of the advanced features.
Advanced object-relational mappings in EclipseLink JPA offers greater flexibility when dealing with complex or legacy relational schemas. This mapping support has evolved over many years of commercial use dealing with many 'interesting' (i.e., challenging) domain models and relational schemas. The resulting support is supported through JPA where possible and configurable with EclipseLink specific mappings when no cooresponding features exists in JPA. As mentioned above, some advanced features are making their way into JPA 2.0 and over time you can expect the use of implementation specific features to decline as the specification evolves.
Converters
Converters allow developers to customize how database values are converted into the domain model and how these values are then written back into the database. This supports user-defined types as well as custom conversion logic that can be used with any mapping. Converters are defined once for a persistence unit and can then be used in any entity through their unique name. All converters implement EclipseLink's Converter interface.
view plaincopy to clipboardprint?
@Converter(name="money-converter", converterClass=mypackage.MyMoneyConverter.class)

...

@Convert("money-converter")
private Money balance; @Converter(name="money-converter", converterClass=mypackage.MyMoneyConverter.class)
...
@Convert("money-converter")
private Money balance;
The above example shows how a developer can write their own converter class and then define it under a user provided name. Once defined, a Converter can be attached to any number of mappings through the @Convert annotation or in an XML mapping file. EclipseLink also provides out of the box converters for handing primitive value and type conversions and some database specific data types.