Bug 27484

Using serialized instances of Java classes for the
purposes of long-term persistence is evil. It
doesn't matter whether the serialization format is
native Java serialization or XML-based (Archiver).
The bad thing is that internal implementation
details get exposed where they shouldn't be.

Using serialized Java objects for module settings
and configuration data introduces architectural
problems and makes applications fragile from the
compatibility point of view. For example

1. internal data structures exposed via
serialization cannot be changed freely
2. obsolete classes need to be sustained in order
to support compatibility with previous versions
3. instances of custom classes provided by modules
cannot be  read by other modules/apps or external
tools 

This requirement applies even to the seemingly
"innocent" utility classes like ArrayList, Vector,
Hashtable, HashMap, String, etc. For the purpose
of long-term persistence, all persistent data
should be translated into a simpler,
JDK-independent form (preferrably XML).

See issue 19915 for the origin of this task.