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\'v

Answer 1

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 2

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 3

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 :)

Answer 4

db4objects might be the best choice

Answer 5

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

Answer 6

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.