serialVersionUID = -1
DKano
cercando di eliminare un po' degli nmila warning che eclipse mi dà su un
progetto, mi accorgo che, per le classi Serializable, occorre definire
serialVersionUID in maniera esplicita (o dare l'opportuna annotation).
Eclipse mi propone tre scelte
- numero a caso
- -1
- annotation per ignorare il warning
Per quel che ne so, se serialVersionUID di un oggetto serializzato è
differente da quello della classe, java si 'altera' e impedisce la
serializzazione. Ho provato a cercare un po' in giro ma non mi è chiaro
se "-1" abbia un particolare significato o sia un numero come gli altri
(e in tal caso, come mai eclipse me lo proponga come scelta differente),
l'unica cosa che ho trovato è uno che dice qualcosa del tipo "... se
pensate che la classe possa cambiare, mettete -1 ...".
grazie dell'attenzione!
--
bye
DKano
Manuel T
> Ciao
> cercando di eliminare un po' degli nmila warning che eclipse mi d� su un
> progetto, mi accorgo che, per le classi Serializable, occorre definire
> serialVersionUID in maniera esplicita (o dare l'opportuna annotation).
Puoi anche impostare il compilatore in modo da non emettere warning se la
classe non ha numero di serie. Secondo me fai prima.
rootkit
> Per quel che ne so, se serialVersionUID di un oggetto serializzato è
> differente da quello della classe, java si 'altera' e impedisce la
> serializzazione. Ho provato a cercare un po' in giro ma non mi è chiaro
> se "-1" abbia un particolare significato o sia un numero come gli altri
> (e in tal caso, come mai eclipse me lo proponga come scelta differente),
> l'unica cosa che ho trovato è uno che dice qualcosa del tipo "... se
> pensate che la classe possa cambiare, mettete -1 ...".
è un numero come un altro. -1L ha solo una particolare rappresentazione
binaria.
rootkit
>> cercando di eliminare un po' degli nmila warning che eclipse mi dà su
>> un progetto, mi accorgo che, per le classi Serializable, occorre
>> definire serialVersionUID in maniera esplicita (o dare l'opportuna
>> annotation).
>
> Puoi anche impostare il compilatore in modo da non emettere warning se
> la classe non ha numero di serie. Secondo me fai prima.
fa prima ma è un modo per cercarsi problemi.
se non viene specificato il serialVersionUID esso viene generato a
compiler time e questa generazione può essere diversa da una compilazione
all'altra sensibile a variazioni della classe ininfluenti. questo si
traduce in errori inaspettati durante la deserializzazione.
il serialVersionUID dovrebbe sempre essere specificato e dovrebbe
cambiare *solo* se esplicitamente si vuole rendere una certa versione di
classe incompatibile con le precedenti. nella stragrande maggioranza dei
casi si può impostare un valore e poi dimenticarsene serenamente.
DKano
> è un numero come un altro. -1L ha solo una particolare rappresentazione
> binaria.
Allora perché eclipse mi propone le due scelte con due differenti
spiegazioni?
1) Adds a default serial version ID to the selected type.
Use this option to add a user-defined ID in combination with
custom serialization code if the type did undergo structural
changes since its first release.
2) Adds a generated serial version ID to the selected type.
Use this option to add a compiler-generated ID if the type did
not undergo structural changes since its first release.
Ma non ho capito praticamente che conseguenze ha scegliere l'una o l'altra.
--
bye
DKano
cicap
> fa prima ma è un modo per cercarsi problemi.
> se non viene specificato il serialVersionUID esso viene generato a
> compiler time e questa generazione può essere diversa da una compilazione
> all'altra sensibile a variazioni della classe ininfluenti.
Ma perché diavolo non fanno un hashcode del nome completo della classe?
Nel caso non sia specificato nessun serialVersionUID.
--
Il CGI secondo Radicale: una specie di linguaggio per fare query su
siti,internet.
rootkit
>> fa prima ma è un modo per cercarsi problemi.
>> se non viene specificato il serialVersionUID esso viene generato a
>> compiler time e questa generazione può essere diversa da una
>> compilazione all'altra sensibile a variazioni della classe ininfluenti.
>
> Ma perché diavolo non fanno un hashcode del nome completo della classe?
> Nel caso non sia specificato nessun serialVersionUID.
perché non è questo lo scopo. dovrebbe, in teoria, variare quando ci
sono cambiamenti al bytecode significativi per la serializzazione, onde
evitare in deserializzazione di creare istanze con valori non corretti.
se cambiasse solo al nome della classe sarebbe inutile...
cicap
> perché non è questo lo scopo. dovrebbe, in teoria, variare quando ci
> sono cambiamenti al bytecode significativi per la serializzazione, onde
> evitare in deserializzazione di creare istanze con valori non corretti.
> se cambiasse solo al nome della classe sarebbe inutile...
Intendo qualora non venisse specificato alcun UID. Tanto in molti casi
già gli sviluppatori non si ricordano di aggiornare il numerino. Tu
stesso hai detto che puoi tranquillamente impostarlo a N e dimenticartene.
rootkit
>> perché non è questo lo scopo. dovrebbe, in teoria, variare quando ci
>> sono cambiamenti al bytecode significativi per la serializzazione,
>> onde evitare in deserializzazione di creare istanze con valori non
>> corretti. se cambiasse solo al nome della classe sarebbe inutile...
>
> Intendo qualora non venisse specificato alcun UID. Tanto in molti casi
> già gli sviluppatori non si ricordano di aggiornare il numerino. Tu
> stesso hai detto che puoi tranquillamente impostarlo a N e dimenticartene.
se non imposti il serialVersionUID significa di fatto che lasci al
compilatore l'onere di decidere se la classe è cambiata in modo
sensibile per la serializzazione. quindi è ovvio che questa valutazione
avvenga secondo criteri oggettivi cioè in base a come sono definite le
proprietà nella classe.
quando parlavo di "dimenticarsene" mi riferivo ai casi comuni quando la
gestione delle versioni è ininfluente e pertanto dimenticanza
consapevole. se invece è influente è chiaro che lo sa il programmatore e
non il compilatore.
Manuel T
> fa prima ma � un modo per cercarsi problemi.
> se non viene specificato il serialVersionUID esso viene generato a
> compiler time e questa generazione pu� essere diversa da una compilazione
> all'altra sensibile a variazioni della classe ininfluenti. questo si
> traduce in errori inaspettati durante la deserializzazione.
Perdonatemi, ho omesso un dettaglio (mica da niente): togliere il warning
solo se non si lavora con la serializzazione.