SerialVersionUID em Projetos JSF [RESOLVIDO]

Vc realmente precisa desse número?

Então, pelo que pesquisei esse número é gerado com base nos atributos da classe, e serve para identifica-la, o problema é que no meu projeto acusa um erro dizendo que tal classe não implementa a interface Serializable, porém, assim que atribuo a interface, aparece outro erro :

error: local class incompatible: stream classdec serialversionUID= 23611651161165116511L , local class serialversionUID = 16518131351616511

eu faço assin

@ViewScoped
@ManagedBean(name = "assuntoController")
public class AssuntoController extends CRUDGenerico<Assunto> implements Serializable {

	private static final long serialVersionUID = 1L;

pois como voce falou se naum implementar Serializable da erro, e assim funciona tudo certinho…

Eu faço o implements Serializable em meus MBs mas nem declaro esse cara.

Nunca tivesse esse erro… O.o

Esse problema é comum de classes que implementam Serializable sem definir o SerialVersionUID.

A nova classe compilada gerou um número diferente do que você tinha antes, agora, o servidor está se batendo entre a “nova” classe e a que você tinha.

Fazer o undeploy do projeto no servidor, e um clean antes de mandar rodar novamente deve ser o suficiente pra ele voltar a funcionar.

Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…

Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?

well.nunes:

Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…

Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?

Primeiro você precisa entender para que ele serve e depois você vê se para sua aplicação é ideal ou não declará-lo.

well.nunes:

Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…

Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?

Não por segurança, mas por lógica, setar o valor de SerialVersionUID é uma boa prática, pois em casos onde a serialização não é temporária voce pode ter sérios problemas, portanto, entenda a serialização e entenda qual valor atribuir a esta propriedade

cleciusjm:

well.nunes:

Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…

Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?

Não por segurança, mas por lógica, setar o valor de SerialVersionUID é uma boa prática, pois em casos onde a serialização não é temporária voce pode ter sérios problemas, portanto, entenda a serialização e entenda qual valor atribuir a esta propriedade

Hebert Coelho:

cleciusjm:

well.nunes:

Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…

Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?

Não por segurança, mas por lógica, setar o valor de SerialVersionUID é uma boa prática, pois em casos onde a serialização não é temporária voce pode ter sérios problemas, portanto, entenda a serialização e entenda qual valor atribuir a esta propriedade

Você teria uma referência disso?
Nunca vi ninguém falando sobre ele como boa prática e gostaria de ver mais sobre isso. =D

Não possuo nenhuma referencia no momento, porém sempre interpretei como uma boa prática porque versionamento declarativo da classe é muito importante em ambientes onde a serialização é muito utilizada. Isso lhe confere o poder de dizer quando uma determinada versão de classe passa a não ser mais retrocompatível com as outra classes do ecossitema.
No caso o exemplo que eu tenho é um sistema de transações financeiras distribuido que trabalha com EJB, e isso permite que ao executar o deploy de um plugin deste sistema eu já tenha a validação se o modelo de DTO existente nesse plugin é compatível com a versão do core que está em runtime. Isso evita muitos erros difíceis de detectar.

cleciusjm:

Não possuo nenhuma referencia no momento, porém sempre interpretei como uma boa prática porque versionamento declarativo da classe é muito importante em ambientes onde a serialização é muito utilizada. Isso lhe confere o poder de dizer quando uma determinada versão de classe passa a não ser mais retrocompatível com as outra classes do ecossitema.
No caso o exemplo que eu tenho é um sistema de transações financeiras distribuido que trabalha com EJB, e isso permite que ao executar o deploy de um plugin deste sistema eu já tenha a validação se o modelo de DTO existente nesse plugin é compatível com a versão do core que está em runtime. Isso evita muitos erros difíceis de detectar.

Valeu. [=

Obrigado a todos pela boa vontade em responder a questão, realmente foi muito esclarecedor, irei estudar mais sobre o assunto…

Boa tarde e obrigado…

Bom, esse ID serve pra dizer se uma versão da classe é compatível com a outra. O que isso quer dizer?

Vamos supor que você tem uma classe Pessoa com um atributo nome, que implementa java.io.Serializable. Essa classe vai ter sim um id associado a ela, quer você defina ou não, se tem dúvidas, é só usar a ferramenta serialver que vem na JDK.

Se um dia você quiser adicionar um atributo sobrenome à mesma classe, você precisa decidir se quer que a versão seja atualizada pra funcionar, ou se os clientes que tem a versão só com o nome ainda podem utilizar a classe sem problemas.

Se você quer que seja atualizado é simples, basta não definir serialVersionUID nenhum, e durante a desserialização, será lançada uma InvalidClassException

Agora se quer que a versão nova seja compatível com a antiga, basta definir o mesmo serialVersionUID para as 2 e pronto.

Agora quanto a ser boa prática ou não, concordo com o Hébert. Ainda mais que se você ficar atualizando o serialVersion cada vez que mexe na classe, está tendo o mesmo resultado que teria se não definisse nada

Rodrigo Sasaki:

Agora quanto a ser boa prática ou não, concordo com o Hébert. Ainda mais que se você ficar atualizando o serialVersion cada vez que mexe na classe, está tendo o mesmo resultado que teria se não definisse nada

Realmente, é no minimo ilógico redefinir o UID a cada alteração, por isto que é importante definir ele sempre em um ambiente onde serialização é utilizada, pois dessa forma voce pode declarativamente determinar que uma versão não é mais retrocompatível, evitando que eventuais pequenas mudanças não geram essa incompatibilidade com o resto do ecossistema.

cleciusjm:

Rodrigo Sasaki:

Agora quanto a ser boa prática ou não, concordo com o Hébert. Ainda mais que se você ficar atualizando o serialVersion cada vez que mexe na classe, está tendo o mesmo resultado que teria se não definisse nada

Realmente, é no minimo ilógico redefinir o UID a cada alteração, por isto que é importante definir ele sempre em um ambiente onde serialização é utilizada, pois dessa forma voce pode declarativamente determinar que uma versão não é mais retrocompatível, evitando que eventuais pequenas mudanças não geram essa incompatibilidade com o resto do ecossistema.

Já li livro falando sobre isso… se não me engano foi o release it que fala sobre vantagem e desvantagem.