Conclusion
File design is an incredibly important topic, and we've left out a vast array of details. For example, for large files, you'll need random access; rather than reading them front to back, you skip around in them. That way, you don't need to read the entire file to access the part at the end. Neither XML nor Java serialization can easily support that sort of random access. The evolution of these file formats is even harder to manage than regular files, because they depend on byte-level access. Small changes to the format result in completely incompatible files.
Another complication in file design comes when you want ACID features (atomicity, consistency, isolation, and durability). These characteristics are associated with transaction features that allow multiple users to access the file simultaneously. For these features, you'll usually use a small database software package such as those from Birdstep or Sleepycat. These lead you into a whole new domain of file format upgrades, both between versions of the database management software and when you alter the database schema.
Despite these complications, there is a lot of call for simple file stores where you expect only one person to use it at a time, and can afford to deal with the entire file at once (or at least sequentially). My advice in these cases is to take versioning into account when you design the files. It'll make both you and your users a lot happier as you maintain the software.