O serialVersionUID e uma duvida constante entre muitos desenvolvedores. Afinal, quando e para que exatamente usa-lo? Devo gerar um numero aleatorio bem grande, ou um numero qualquer? Essas perguntas sao comuns, e ao desenvolvedor experiente e necessario conhecer a fundo esse detalhe do processo de serializacao do Java.Quando um objeto e serializado no Java, essa sequencia de bytes, alem de conter seus atributos de instancia nao transientes, carrega consigo um numero que indentifica a versao da classe que foi usada durante o processo. Esse e o chamado serialVersionUID, ou seja, o indentificador de versao de serializacao de uma classe. Esse numero e utilizado para saber se o objeto que estamos recuperando e de uma versao compativel com a versao da classe que foi utilizada quando serializamos o objeto: em outras palavras, os arquivos .class nao precisam ser necessariamente os mesmos para que o processo de serializacao ocorra com sucesso.Por exemplo, considere a seguinte classe Usuario:package br.com.caelum; public class Usuario implements Serializable { private String login;}Essa classe possui o serialVersionUID igual a 2806421523585360625L. Esse numero nao e aleatorio! Ele e um hash (SHA) calculado em cima dos nomes dos seus atributos, e assinaturas dos metodos em uma ordem bem definida pela especificacao do processo de serializacao. E como eu sei esse numero? O JDK vem com a ferramenta serialver, que implementa esse mesmo hash:serialver br.com.caelum.UsuarioSe o serialVersionUID utilizado durante a serializacao nao bater exatamente com oserialVersionUID da classe que esta sendo usada para recuperar essa informacao, uma exception e lancada: java.io.InvalidClassException.Por exemplo, se adicionarmos um novo atributo na nossa classe Usuario:public class Usuario implements Serializable { private String login; private String senha;}Agora teremos o serialVersionUID valendo 416295346730660862L. Caso voce serialize umUsuario com a primeira classe aqui definida, e tentar recuperar essa informacao usando essa nova versao de classe, receberemos a conhecida java.io.InvalidClassException. Esse e o comportamente que em muitos casos queremos, mas algumas vezes fazemos pequenas modificacoes na classe as quais percebemos que nao impactarao no processo de serializacao, e precisamos manter compatibilidade com a versao antiga daquela classe. Para isso, basta definirmos explicitamente qual e o nosso serialVersionUID, e no caso de querer manter compatibilidade com a classe Usuario anterior, vamos utilizar o valor de serialVersionUID que seria gerado pela JVM: 2806421523585360625L. O codigo ficaria:public class Usuario implements Serializable { private static final long serialVersionUID = 2806421523585360625L; private String login; private String senha;}As vezes recebemos um warning do Eclipse, e ele pede para que seja definido oserialVersionUID da classe em questao. Isso ocorre porque voce implementa Serializable ou uma de suas maes a implementa. O Eclipse entao te abre tres opcoes: utilizar o@SurpressWarnings para voce assumir o risco, usar um valor default, ou usar o valor gerado. O gerador de UIDs do Eclipse e exatamente o mesmo gerador utilizado pelo Java SE para criar os UIDs padrao! Reforcando, esse numero nao e um numero aleatorio!Quando alguem esquece de manter o mesmo serialVersionUID para duas versoes compativeis de uma classe, podemos ter problemas em usar diferentes versoes do software que sao teoricamente compativeis. Isso muitas vezes acontece em servidores de aplicacao, e se