My Thoughts on EclipseLink 1.0

We released EclipseLink 1.0. You can read about it on the EclipseLink Team Blog. Please do download it and try it out.

Its been an interesting year since we first announced the contribution of Oracle TopLink to open source and the creation of the EclipseLink project. Taking a large product and all of its testing and moving it to a new repository with new build and test servers was technically challenging. Probably the more interesting changes however have been in how we developed 1.0 and the future releases of the project. Learning the Eclipse 'way' (project reviews, code contributions and the IP process, detailed road maps and public updates, web site, portal, wiki, bugzilla, ...) has been fun and interesting while only occasionally painful. Transitioning a large development team to this new open process was well worth the effort. We are now a community of committers that expands beyond just Oracle.

This 1.0 release is really based on several years of development. This past year within the EclipseLink project plus all of the functionality developed in Oracle TopLink since our 10.1.3 release (February 2006) is included. While we tend to focus on the efforts of the past year many Oracle TopLink customers will find a significant amount of new features in the classic ORM/OXM support in addition to all the great new JPA/JAXB/SDO support. Over the next few weeks I will try to post blogs highlighting many of these features and how they can be used.

There are a few high level items about this release I would like to point out:

Minimal Dependencies: We ship with an eclipselink.jar library for JavaSE/EE users that can be used easily with minimal additional libraries. JPA users in JavaSE will just need to include the JPA 1.0 library (included as /jlib/jpa/persistence_1.0.0.jar) and their favourite JDBC driver. Within a JavaEE5 container you will just need the EclipseLink library as JPA should already be available as well as your JDBC drivers within the container's Data Source. Minimal dependencies is very important as it simplifies usage and avoids conflicts with other frameworks and your container's use of common libraries.

Full Functionality: No matter how many times I say this I still get questions after my talks and webinars. All of the persistence functionality of Oracle TopLink is included in EclipseLink. All of the TopLink development team now exclusively develops new functionality in EclipseLink.

We have also done a fair bit of work to enable the usage of our many advanced features through JPA. This includes custom annotations as well as XML configuration. Our goal is to keep developers as close to standard JPA as possible and simplify usage when you do need EclipseLink JPA's advanced features.

OSGi Support: While I still personally feel like a newbie in the OSGi space I am very proud of how our developers have managed to address class-loader flexibility so that we can bundle our EclipseLink components for use in OSGi. The optional Equinox functionality to enable Dynamic/Load-Time weaving allows developers using Equinox (typically RCP) to build full featured JPA applications without fighting the persistence implementation. We have an example available if you want to try it out.

Flexible Object Binding: The MOXy component does support JAXB2's annotations and XML schema compiler but what I think is most interesting is the ability to externalize the XML binding information. EclipseLink MOXy has its own XML mapping file as well as supporting mappings defined in code (statically or dynamically). Using this externalized mapping support with the standard JAXB marshal/unmarshal API is very powerful and allows a domain model to be easily persisted to multiple data sources/formats.

Performance and Scalability: One aspect of Oracle TopLink development is that while we continued to evolve the product over the past 12 years we have always focussed on ensuring we had a well tuned core engine and many tuneable options available so our customers can address their performance and scalability goals. The Oracle TopLink product has been a key contributor to Oracle's world record SpecJ benchmarks and all of the optimizations introduced to address high levels of concurrent processing are now available in EclipseLink. We believe we have the fastest persistence solution available and will work hard to continue proving that through public benchmarking activities.

I would like to thank everyone involved in making the EclipseLink 1.0 release happen. From the developers/QA/writers/managers who helped produce it (and put up with me) to the Oracle management who supported us through this process and all of our user community for the feedback and encouragement.

Cheers,

Doug

Graduation

Its been a big week for graduations. Earlier this week my son completed his time in kindergarden and today the EclipseLink project graduated from incubation status. Tonight I took a few minutes to finally remove the big egg from the EclipseLink home page.

As for my son, he is pretty focussed on spending every waking hour swimming until September. As for EclipseLink we are about ready to ship our 1.0 release on July 9th. In both cases it should be a fun and exciting summer.

We have been getting great feedback so far on EclipseLink and I would like to invite the entire Java community to download EclipseLink and try it out. We are eager to get your feedback and continue to expand the usage of our project.

Doug

EclipseLink in the News

Pretty exciting day so far at EclipseCon. We have been involved in two press releases at the conference so far.

Eclipse Announces EclipseLink Project to Deliver JPA 2.0 Reference Implementation

• Read more on the EclipseLink Team BLOG

Eclipse Announces New Runtime Initiative around Equinox

Ian Skerrett discusses this announcement and its implications. This announcement has a couple effects to the EclipseLink project. First off it provides a new top level project for us. We will move from the Technology project to the newly created Runtime project in the near future. This also formalizes our relationship with Equinox. We will soon be checking in our work to enabled EclipseLink's effective use in an OSGi environment.

Now that we have these announcements out I am looking forward to spending more time talking to other attendees about their work and how EclipseLink may be of use in their projects and applications.

Doug

Testing EclipseLink JPA applications in JavaSE

I spend part of my work days writing examples and helping users debug issues. I spend the majority of this time using JPA with our TopLink and now EclipseLink's advanced features.

One little piece of code I always find myself looking for is a way to take a JPA persistence unit configuration and use it in JavaSE without changing it. The idea is that my persistence unit which should run in the container should also be testable easily outside.

In the past I posted some examples of using XML to accomplish this but the following is the Java code that I use in my JavaSE examples and unit tests without going down the road of a separate persistence unit definition in XML for both worlds.

import static org.eclipse.persistence.jpa.config.PersistenceUnitProperties.*;

...

Map properties = new HashMap();

// Ensure RESOURCE_LOCAL transactions is used.
properties.put(TRANSACTION_TYPE,
  PersistenceUnitTransactionType.RESOURCE_LOCAL.name());

// Configure the internal EclipseLink connection pool
properties.put(JDBC_DRIVER, "oracle.jdbc.OracleDriver");
properties.put(JDBC_URL, "jdbc:oracle:thin:@localhost:1521:ORCL");
properties.put(JDBC_USER, "user-name");
properties.put(JDBC_PASSWORD, "password");
properties.put(JDBC_READ_CONNECTIONS_MIN, "1");
properties.put(JDBC_WRITE_CONNECTIONS_MIN, "1");

// Configure logging. FINE ensures all SQL is shown
properties.put(LOGGING_LEVEL, "FINE");

// Ensure that no server-platform is configured
properties.put(TARGET_SERVER, TargetServer.None);

I can then create my EntityManagerFactory using:

Persistence.createEntityManagerFactory("unit-name", properties);

The only remaining struggle I have is specifying which classes are my entities. The simplest way is to explicitly reference them in the persistence.xml or an associated orm.xml file. If they are listed explicitly then I do not need to worry about the automatic discovery.

EclipseLink does support automatic discovery of entity classes in JavaSE but you need to enable its usage using:

<persistence-unit name="unit-name">
<exclude-unlisted-classes>false</exclude-unlisted-classes>
</persistence-unit>

Hopefully having these snippets of code and XML handy will help some of you out and now I can easily find them wherever I am working.

Doug

Java Search Engine Integration for EclipseLink JPA

The creator and primary contributor to Compass has taken the initiative to provide support for using EclipseLink (www.eclipselink.org) with Compass. I hope to find the time to build an application that illustrates the use of the two projects but thought I would post some early information to the community about the integration.

See the documentation


Compass is described as:

Compass is a first class open source Java Search Engine Framework, enabling the power of Search Engine semantics to your application stack decoratively. Built on top of the amazing Lucene Search Engine, Compass integrates seamlessly to popular development frameworks like Hibernate, [and now EclipseLink] and Spring. It provides search capability to your application data model and synchronizes changes with the datasource. With Compass: write less code, find data quicker.

For those of you interested in adding richer search capabilities to your JPA applications you can now combine the capabilities of Lucenewith EclipseLink JPA through the Compass integration.

Cheers,

Doug