If you accept the default serialized form and later change a class’s internal representation, an incompatible change in the serialized form will result. Clients attempting to serialize an instance using an old version of the class and deserialize it using the new one (or vice versa) will experience program failures. It is possible to change the internal representation while maintaining the original serialized form (using ObjectOutputStream.putFields and ObjectInputStream.readFields), but it can be difficult and leaves visible warts in the source code.
To be fair, this is a problem not specific to Java serialization. As classes evolve, compatibility with data in older forms requires some handling and warts. Yea, some handle it better or more gracefully than others.
I've said this before elsewhere (and I have a feeling a subsequent item will recommend this[1]): consider separating the code that performs serialization from the class that it's serializing (where "serialization" can refer to the process of converting Java data into non-Java, cross-platform structured data formats). This keeps class logic cleanly separated from serialization code/mess. Consider also that you may have to deal with exporting/importing data from several sources (read: have multiple serialization formats) — database and clients, and even multiple types of clients — not to mention the possibility that you may wish to migrate from one format to another.
This is very analogous to (and related to, actually) keeping string formatting separate[2] from the data/logic class (where it was even recommended that `toString()` could be used for "serialization").
[1] Yup —kinda —Item 90
[2]https://www.goodreads.com/notes/37646821-effective-java/74-robert/cd025f84-7dcb-4402-86a3-13ae1acf2050?ref=rnlp
