Instant Run and Serializable

When Google announced Instant Run a year or so ago, I was skeptical. The objective of faster builds is wonderful. The specific technique — runtime classloader games — struck me as a “death by 1000 paper cuts” solution. Most of the time, it probably works fine. Sometimes, it might not, due to peculiarities in the code or resources.

Xav Ducrohet points out one such peculiarity: Serializable.

Many developers make a class Serializable simply by adding implements Serializable to the class definition. That’s sloppy, but it works in some situations. The better approach is to also add a definition of serialVersionUID — or, as the JavaDocs put it, “It is highly recommended to use an explicit serialVersionUID field to avoid compatibility issues.”

If you skip serialVersionUID, the VM generates one for you, “based on various aspects of the class”. As it turns out, the generated serialVersionUID will be different for a version of your class injected via Instant Run, compared with the same class packaged in your APK. If you use Serializable for persistence, with ObjectOutputStream and kin, objects saved when running under Instant Run may not be compatible when you try loading them with the APK edition of your Serializable class, and vice versa.

Hopefully this specific problem affects few developers, as hopefully few developers use Serializable for persistence. If you have classes in a library that are Serializable, please add serialVersionUID if you have not done so already, as while you might not be persisting instances of your classes, users of your library might. With luck, the tools might complain more when this is missing.