John O'Conner's Blog

Using the Java Persistence API on the desktop

I'm always excited when I can get in on the fun those EE guys seem to have all the time. My latest exploration into the EE spec has helped me find another little treasure that I can bring back to the desktop: the Java Persistence API (JPA).

I've been tinkering, tossing in a JPA annotation here and there, discovering how to use the JPA in my desktop applications. I'm convinced that it's not so hard.

So, why would you want to use the JPA in your desktop apps? For one thing, the API is pretty simple. At the most basic level you have persist, find, merge, and remove methods. Second, you can branch out to full Java Persistence query language, a relative of Enterprise JavaBeans query language, when you want the full power of selecting, updating, and deleting entities using expressive queries that work with plain old Java objects (POJOs) in your applications. And don't forget that when you use the Java Persistence query language, your queries will work across multiple databases. You don't have to write vendor-specific SQL for each different db that you support. Write in this query language once, and your queries work everywhere. Hey, haven't I heard something like that before?

OK, I reread that last paragraph. There's nothing specific there about why this is good for desktops. Maybe that's another good point. You can use the same persistence framework for your desktop apps that you use for the web-based ones. That's worth something.

What do you need to get started with the JPA? You need a reference implementation for starters. You can get that from the GlassFish project. No need to download the whole GlassFish server. You just need the persistence API. You can download the Java Persistence implementation separately. You might also want the spec itself. You can get that from the EJB spec. It's a smaller subsection that you can retrieve as a PDF file. It's part of the JSR 220 JSR.

Got the spec? Got the implementation? Oops, one last thing. You have to have a database. I'm using Java DB myself. That's Sun's branded version of the Apache Derby project. Sun branded? Yes, if you get the Sun version, you have options for support. The db is free of course, but you can purchase support plans too...or not. It's entirely up to you.

Comments

• I was hoping you had some steps written up about deploying it. :)

  Posted by: hhuynh on April 26, 2007 at 10:18 AM

• What technologies have you used previously on the desktop for persistence?

  Posted by: niallp on April 27, 2007 at 05:22 PM

• MySQL, JDBC. My own DAOs and entity-relational mappings. Nothing fancy.

  Posted by: joconner on April 27, 2007 at 09:50 PM

• The last few week I've also tried to use JPA in a fat client, even with a reverse engineer approach (using an extends to the reversed class) because I hate to have to do every DML twice.

  The initial signs are positive; this reveng approach works using Toplink. OpenJPA has some problems, but the fixes are already under way. So I'm quite happy.

  The only problem is that Toplink opens (per default) 7 connections per client. This can be reduced to 2. However, the situation I'm in already has an existing JDBC connection, so that are 3 connections per client.

  I think using JPA in desktop is very feasible, but the library are not yet tuned for this use.

  Posted by: tbee on April 29, 2007 at 11:35 PM

• Another interesting technologyfrom the enterprise world for persistence is the Java Content Repository. I'm embedding the Apache implementation Jackrabbit into our app right now, and I'm finding it's a great high level solution for us. Jackrabbit has a bunch of deployment models ranging from directly embedded into your desktop app all the way up to running as a servlet with RMI and WebDAV wrappers. Out of the box, it comes bundled with Derby and Lucene, so deployment is nothing more than including a couple of jars, at least for non-enterprise-sized repositories. If your repository is going to get huge, you probably want to use something more robust than Derby, but the underlying persistence engine is pluggable, and you have quite a few choices.

  JCRs provide a hierarchical containment model, but they also let you use referencable nodes (with referential integrity) to escape the limitations of a tree and get something more open-ended like a graph. If you can make your content models fit into the JCR containment model, you can get the benefit of transactional sessions, version control with a per-node granularity, a simple schema definition language, automatic XML I/O, a simple DOM-like traversal API, your choice of XPath or SQL for querying, and more.

  I'd love to see your thoughts about how it stacks up as another persistence tool for desktop apps:

  http://jackrabbit.apache.org

  Posted by: willismorse on April 30, 2007 at 07:13 AM

• All the JPA providers have huge startup time ..to prepare their meta-data structure ... So JPA is ruled out for desktop app with even a medium sized domain model ...

  Posted by: scarface_548 on May 01, 2007 at 04:13 PM

• I have just read the specification pdf. The xml schema is only ...30 pages. The whole system is way more complex than it need to be. Why couldn't it be like db4o?

  Db4o is dead simple: you open the persistent storage, you write your objects in it, and then you get the objects back using Java as a query language. Schema evolution is automatic, it works in a client/server architecture, and it even contains functionality not possible with JPA, like sending an algorithm to the server, instead of getting the data to the client.

  Posted by: axilmar on May 11, 2007 at 07:44 AM

This work is licensed under a Creative Commons License.