What's the best way to persist data in a Java Desktop Application?

Question

I have a large tree of Java Objects in my Desktop Application and am trying to decide on the best way of persisting them as a file to the file system.

Some thoughts I've had were:

• Roll my own serializer using DataOutputStream: This would give me the greatest control of what was in the file, but at the cost of micromanaging it.

• Straight old Serialization using ObjectOutputStream and its various related classes: I'm not sold on it though since I find the data brittle. Changing any object's structure breaks the serialized instances of it. So I'm locked in to what seems to be a horrible versioning nightmare.

• XML Serialization: It's not as brittle, but it's significantly slower that straight out serialization. It can be transformed outside of my program.

• JavaDB: I'd considered this since I'm comfortable writing JDBC applications. The difference here is that the database instance would only persist while the file was being opened or saved. It's not pretty but... it does lend itself to migrating to a central server architecture if the need arises later and it introduces the possibility of quering the datamodel in a simpler way.

I'm curious to see what other people think. And I'm hoping that I've missed some obvious, and simpler approach than the ones above.

---

Here are some more options culled from the answers below:

• An Object Database - Has significantly less infrastructure than ORM approaches and performs faster than an XML approach. thanks aku

Answer 1

I would go for the your final option JavaDB (Sun's distribution of Derby) and use an object relational layer like Hibernate or iBatis. Using the first three aproaches means you are going to spend more time building a database engine than developing application features.

Answer 2

Have a look at Hibernate as a simpler way to interface to a database.

Answer 3

In my experience, you're probably better off using an embedded database. SQL, while less than perfect, is usually much easier than designing a file format that performs well and is reliable.

I haven't used JavaDB, but I've had good luck with H2 and SQLite. SQLite is a C library which means a little more work in terms of deployment. However, it has the benefit of storing the entire database in a single, cross-platform library. Basically, it is a pre-packaged, generic file format. SQLite has been so useful that I've even started using it instead of text files in scripts.

Be careful using Hibernate if you're working with a small persistence problem. It adds a lot of complexity and library overhead. Hibernate is really nice if you're working with a large number of tables, but it will probably be cumbersome if you only need a few tables.