Java swing application save custom file format

i'am writing some swing applications(not rich clients, running standalone) with a lot of domain models. Those are Java Beans, bound to the UI via presentation models.

Now i need to save all the domain data in some kind of a custom project file format.

The software will go through many versions, in wich the domain models always change a little bit. I need to maintain backwards compatibility. I really don't开发者_如何学Go know what could be the best approach to this.

I've thought about java serialization. But that seems to be a lot of low level work, implementing custom serialization carefully, for all the models. Especially if i consider the backwards compatibility part.

A bit of a better approach seems to be using hibernate and its annotations to persist the domain model. But wich database could i use for this? Can i get into problems connecting to the database because it can't be fully integrated (no communication over a port on localhost => firewalls etc.). Also, saving some files by using a orm and a database as middleware, seems a little bloated anyway.

To summarize it: I'am relatively new to java and now programming large scale swing applications. I've got nearly no experience with serialization(but i've got Effective Java :D), JPA and hibernate, available java databases and so on.

Can anyone give me a hint, please? :)

Using hibernate is a good possibility.

Some embedded database exist , so you could launch it when the application starts before starting hibernate.

The advantage of course is that if you ever wanted to convert the code from standalone to server based, your java bean - hibernate - db model would work very well in that context as well. Serializing to your own format would be like making your own flat file database, and why write it again when it's already done for you And I was also going to suggest Apache Derby for embedded use (From: Java Drinker)

For the migration part, the easiest way is then to have a version table in the database, telling you what is the current version, and then at the start of the application, after the database is started, but before creating the session factory (or entity manager) check the current database version, check in a sql migration file the last version, and if both do not match, exec all sql queries above the current db version.

The migration file could look like that :

-- version:1
sql query 1 (update, alter, ...)

-- version:2
sql query 2

...

You will have to be very careful when you write the migration file. Always consider there is data in a table for example (never add a not nullable column in a table but instead add the column, update the column, and then add the non nullity constraint).

[edit]

• First import part :

If the database does not exist or is empty (for example the version table is not there), you start by creating the database and then start a migration from your old format to the database format. The code would look like: reading old data files, instantiating your hibernate/jpa entities, and persisting them. (you can also write more efficient code to produce directly sql queries, but that will need more time, and will be a lot harder to maintain when your jpa model change)

• export :

The embedded database will have its own files on disk. It will be enough to share data between different workstations.
If you want to share the data with other apps, you will need to develop this opposite feature of import : loading all the needed entities from database and writing them to a different file format. It could be triggered from your application ui.

Using JPA you could save all info into any of JSON/XML/Excel/ODF format, if using DataNucleus as a JPA implementation (as long as the data needing saving is suitable for persisting using JPA). Depends on the data, but of those formats listed something like XML could be more suitable.

--Andy (DataNucleus)

I'am using XStream now. The sweet spot is, that with a little configuration i don't need to modify my model - saving/loading just works out of the box.

Versioning will probably be done using XSLT to transform older save files into their newer versions. Actually that would be very straight forward, since i can save an old file, save a new file and just write XSLT for the difference.