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.

Thanks in advance, Allain

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

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

Answer 2

XStream from codehaus.org

XML serialization/deserialization largely without coding. You can use annotations to tweak it. Working well in two projects where I work.

See my users group presentation at http://cjugaustralia.org/?p=61

Answer 3

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 4

db4objects might be the best choice

Answer 5

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.

Answer 6

I think it depends on what you need. Let's see the options:

1) Descarded imediatelly! I'll not even justify. :)

2) If you need a simple, quick, one-method persistence, stick with it. It will persist the complete data graph as it is! Beware of how long you'll be maintaning the persisted objects. As yourself pointed out, versioning can be a problem.

3) Slower than (2), need extra code and can be edited by the user. I would only use it the data is supposed to be used by a client in another language.

4) If you need to query your data in anyway, stick with the DB solution.

Well, I think you had already answered your question :)