The Eclipse Persistence Services project (EclipseLink) has completed its incubation phase and the 1.0 release is available for download. This release completes the transition of the persistence functionality developed in Oracle TopLink to being fully developed and maintained as an open source project at Eclipse. This also signifies the first release of a project under the recently created top-level Runtime (RT) project at Eclipse. EclipseLink delivers persistence services for efficiently working with Java and relational, XML, and non-relational data sources. The highlights include: · Compact: Standard Java distribution is composed of a single implementation jar and utility jars that can be used in any Java SE, IDE, or Java EE hosted environment. · OSGi: EclipseLink is also available as asset of OSGi bundles. This distribution offers out of the box support for compliant OSGi implementations, as well as Equinox-specific extensions. A more verbose posting is available on our team blog: http://eclipselink.blogspot.com/2008/07/eclipseline-10-released.html. · JPA: Superior Java Persistence API 1.0 implementation with many advanced features offering greater flexibility and performance for mapping, caching, querying and transaction processing. · MOXy: Object-XML binding support with JAXB, offering highly flexible mappings as well as a meet in the middle configuration approach. · SDO: Service Data Objects 2.1 implementation enabling flexible service integration with dynamic and static models. · Utils: Migration utilities to assist developers currently using Oracle TopLink or TopLink Essentials in their upgrade to EclipseLink as well as the workbench for compatibility with classic object-relational and object-XML mapping. A complete index of features and the full user documentation for EclipseLink is available on the EclipseLink wiki. We encourage the Java community to try out the 1.0 EclipseLink release and provide feedback. Your contributions and suggestions are valuable to us and will help ensure the project meets your current and future needs.

with this move,do u as a hibernate developer will switch to EclipseLink? or in other way,did u used hibernate before because it was free?or because it is the best joe

Without wanting to start a Hibernate vs EclipseLink flame thingy here, I would like to share my experiences. For my setup Toplink JPA / Toplink Essentials / EclipseLink was the only solution. I have a three layered business model: - an unpersisted AbstractBean class - on top of that a reverse generated @MappedSuperclass bean - on top of that a generated, but initially empty, @Entity bean, which is intended to hold code that should not be overwritten by the reverse generated code. This setup could not be persisted by Hibernate, but EclipseLink worked perfectly. So I had only one option.

EclipseLink has some query in memory support. It's currently limited but could be extended must more easily than writing from crash the same feature in Hibernate. Query in memory enabled couple of features. First, index support could easily be added and put EclipseLink in top of Hibernate in the technology side. Having index, make caching easy and performing in the case that cache key is something else than the primary key. Also because EclipseLink can query in memory, invalidation of query cache and flush subset can be minimized so better performance. In other words, instead of flushing everything or invalidating all the query cache, query in memory allow flush/invalidate only the relevant data. Conform in unit of work, which use query in memory, was used in TopLink 10.x to patch its inability to flush, but could be leveraged to make the best implementation of Seam conversation, less staleness. Cache hit on query is not just on primary keys with TopLink. The implementation currently support extra where clause AND with the primary key. However, lot more could be added with few efforts. For example, if index would be supported, cache hit could be transparent on query against unique index. However, before EclipseLink/TopLink move out from its lethargy. I see EclipseLink as a risky prototype that is only tested for lab use and supported by a weak QA organization. I think the project need new leaders to become viable.

Sebastien, I firmly believe our caching and UnitOfWork functionality are the best available in any ORM available. There has been some interest in additional cache indexing to further leverage in-memory and conforming query capabilities. Yes, these do offer amazing benefits in long lived transactions. With your knowledge of TopLink it would be great to have you more actively and involved in future versions of EclipseLink. I disagree strongly with your last two statements about a weak QA organization and more personally on the leadership front. On a nightly basis we run over 22,000 unit tests on the Eclipse foundation servers. We then also bring the nightly build within Oracle and run additional server tests using WebLogic, WebSphere, JBoss and Spring containers as well as additional databases. That is just he nightly runs. At each release we also expand this testing across additional containers and versions as well as databases and drivers. Please feel free to review the tests cases which are all in the EclipseLink SVN repository. TopLink has a large customer base and the feedback we have received so far on EclipseLink has been great. Customers have migrated from TopLink Essentials and earlier Oracle TopLink versions with ease. Your hypothesis that EclipseLink is a "risky prototype" is simply not founded in fact. As part of the EclipseLink project's leadership I strongly believe we are doing a good job of running an open and transparent development process and delivering functionality based on our community's requests. Please engage with the project team directly on the newsgroup and mailing lists. We are always interested in constructive feedback and requirements for future versions. Doug

This article gives a nice overview with code samples: http://eclipse.dzone.com/articles/introducing-eclipselink

I just spent a few minutes and upgraded Compass to work with EclipseLink 1.0. It will be available in the upcoming 2.0.2 and 2.1 M1. So, if you need to have a "Searchable" Eclipse Link, here is a good place to start. Cheers, Shay Banon

I really would love to know how the three Oracle "Products" relate: Toplink Essential: https://glassfish.dev.java.net/javaee5/persistence/ EclipseLink: http://www.eclipse.org/eclipselink/ Toplink Oracle : http://www.oracle.com/technology/products/ias/toplink/index.html It's totally unclear to a "casual" user, the see what the three Oracle driven Projects mean in terms resource (people and money), code, functionality and planning. Worst case we would have a typical "branch" syndrom: three branches going no where. Well probably not. But then what is the motivation of Oracle? I really would prefere to see concentration of resources and a "rewrite" of Toplink. Toplink is the oldest O/R Mapping technology outthere, over 10 years, i think and originated in Smalltalk Code. Lots of exerience there, but probably, if they could do it again, they would make some other decisions, like the code more independent of a distribuation model (client /server) and other stuff. Then they maybe could make a difference.

Christoph, The short answer here is that EclipseLink is the convergence of the 3 "products" listed . Going forward all development is being done in the EclipseLink project. Oracle TopLink will continue as Oracle's commercial Java persistence offering but will be a distribution of EclipseLink. TopLink Essentials has already been replaced by EclipseLink JPA in GlassFish V3. Doug

Maybe DataNucleus Access Platform offers a better alternative because of its standard uniform interface API (JDO 2.1) and query language (JDOQL), over a number of etherogeneous backend (RDBMS, DB4O, NeoDatis, JSON, XML, Excel, LDAP). Guido