serialVersionUID
facilita o controle de versão de dados serializados. Seu valor é armazenado com os dados ao serializar. Ao desserializar, a mesma versão é verificada para ver como os dados serializados correspondem ao código atual.
Se você deseja versionar seus dados, normalmente começa com um serialVersionUID
de 0 e aumenta com todas as alterações estruturais em sua classe que alteram os dados serializados (adicionando ou removendo campos não transitórios).
O mecanismo interno de desserialização ( in.defaultReadObject()
) se recusará a desserializar das versões antigas dos dados. Mas se você quiser, pode definir sua própria função readObject (), que pode ler dados antigos. Esse código personalizado pode então verificar oserialVersionUID
para saber em qual versão os dados estão e decidir como desserializá-los. Essa técnica de versão é útil se você armazenar dados serializados que sobrevivem a várias versões do seu código.
Mas armazenar dados serializados por um período de tempo tão longo não é muito comum. É muito mais comum usar o mecanismo de serialização para gravar temporariamente dados em, por exemplo, um cache ou enviá-los pela rede para outro programa com a mesma versão das partes relevantes da base de código.
Nesse caso, você não está interessado em manter a compatibilidade com versões anteriores. Você está preocupado apenas em garantir que as bases de código que estão se comunicando realmente tenham as mesmas versões de classes relevantes. Para facilitar essa verificação, você deve manter oserialVersionUID
procedimento anterior e não se esqueça de atualizá-la ao fazer alterações em suas classes.
Se você esquecer de atualizar o campo, poderá acabar com duas versões diferentes de uma classe com estrutura diferente, mas com a mesma serialVersionUID
. Se isso acontecer, o mecanismo padrão ( in.defaultReadObject()
) não detectará nenhuma diferença e tentará desserializar dados incompatíveis. Agora você pode acabar com um erro de tempo de execução enigmático ou falha silenciosa (campos nulos). Esses tipos de erros podem ser difíceis de encontrar.
Portanto, para ajudar esse caso de uso, a plataforma Java oferece a opção de não definir o serialVersionUID
manual manualmente. Em vez disso, um hash da estrutura da classe será gerado em tempo de compilação e usado como id. Esse mecanismo garantirá que você nunca tenha estruturas de classe diferentes com o mesmo ID e, portanto, não obterá essas falhas de serialização de tempo de execução difíceis de rastrear mencionadas acima.
Mas há uma desvantagem na estratégia de identificação gerada automaticamente. Ou seja, os IDs gerados para a mesma classe podem diferir entre os compiladores (conforme mencionado por Jon Skeet acima). Portanto, se você comunicar dados serializados entre códigos compilados com diferentes compiladores, é recomendável manter os IDs manualmente de qualquer maneira.
E se você é compatível com os seus dados, como no primeiro caso de uso mencionado, provavelmente também deseja manter o ID por conta própria. Isso para obter identificações legíveis e ter maior controle sobre quando e como elas mudam.