[Java] Serializzazione compatibilità SerialVersionUID

[robb7582]

Ho verificato che eclipse solo per le classi serializzabili genera un warnings che viene risolto solo generando un SerialVersionUID che se non ho capito male servirebbe per far funzionare la serializzazione e la deserializzazione durante il trasferimento della istanza di una classe compilata con una versione della jvm diversa da quella della macchina di destinazione che deserializza giusto?Ma allora vorrei sapere:

1)se io in una classe uso una conessione a db (non serializzabile)e altri oggetti invece serializzabili, riesco a serializzare gli altri oggetti cioè mi arriva la classe e riesco a deserializzare e ricostruire l'istanza contenente valorizzati (salvati = serializzati) gli altri oggetti escluso la connessione al db (dichiarate statiche o transient oppure niente)?

2)ma se io uso un compilatore diverso tra le due macchine dove avviene il traferimento, la cosa sopra la posso fare visto che non cè la possibilità di generare un serialVersionUID?Visto che ho letto che se non si mette le due macchine controllano che le classi siano uguali generando un UID di default che pero' è diverso da JVM a JVM..

Grazie!

Roby

[LeleFT]

1) Il SerialVersionUID viene sempre autogenerato dalla JVM. Serve solo a capire se una determinata classe che viene serializzata sia compatibile o meno con la versione della JVM che tenta di eseguirla.

2) Non esistono "diversi compilatori": il compilatore per Java è uno ed unico, si chiama javac e viene utilizzato da qualsiasi editor (NetBeans, Eclipse, BlueJ, ecc).

3) Solo le classi serializzabili possono essere serializzate. Esse devono prevedere un costruttore di default (vuoto) e qualsiasi campo che al loro interno non sia serializzabile deve essere dichiarato come "transient".


Ciao.

[robb7582]

Ok ho capito bene la risposta del punto3, hai ragione al punto 2 perchè ho scritto compilatore per sbaglio ma intendevo la versione della JVM, pero' per il punto 1 se io ho una classe che ha oggetti non serializzabili non mi genera l'uid nè con eclipse ne usando il tool serialver, ma tu dici al punto tre che se li dichiaro transient lo dovrebbe generare?? no perchè io faccio emigrare del codice che istanzio su una macchina, su altre macchine che potrebbero avere JVM diverse quindi a quanto ho capito servirebbe generare il serialUID no??

Originariamente inviato da LeleFT
1) Il SerialVersionUID viene sempre autogenerato dalla JVM. Serve solo a capire se una determinata classe che viene serializzata sia compatibile o meno con la versione della JVM che tenta di eseguirla.

2) Non esistono "diversi compilatori": il compilatore per Java è uno ed unico, si chiama javac e viene utilizzato da qualsiasi editor (NetBeans, Eclipse, BlueJ, ecc).

3) Solo le classi serializzabili possono essere serializzate. Esse devono prevedere un costruttore di default (vuoto) e qualsiasi campo che al loro interno non sia serializzabile deve essere dichiarato come "transient".


Ciao.

[andbin]

Originariamente inviato da LeleFT
1) Il SerialVersionUID viene sempre autogenerato dalla JVM. Serve solo a capire se una determinata classe che viene serializzata sia compatibile o meno con la versione della JVM che tenta di eseguirla.

La versione della JVM non centra nulla. SerialVersionUID serve per stabilire durante la deserializzazione se i dati sono compatibili con la classe. Ho una classe A, ne serializzo dei dati su db, file, dove ti pare. Successivamente modifico la classe A (es. aggiungo/tolgo variabili di istanza, ecc....) e cerco poi di deserializzare quello che ho serializzato prima. La classe è ancora compatibile?? Per questo serve SerialVersionUID.

Originariamente inviato da LeleFT
3) Esse devono prevedere un costruttore di default (vuoto)

No, questo non è un requisito. La cosa veramente importante è che le super-classi siano pure loro serializzabili oppure, se non lo sono, abbiano un costruttore no-arg.

[doraemon83]

Non vorrei sbagliare ma credo che servano anche tutti i getter e setter dei campi

[andbin]

Originariamente inviato da doraemon83
Non vorrei sbagliare ma credo che servano anche tutti i getter e setter dei campi

Se ti riferisci alla super-classe non serializzabile con costruttore no-arg, allora non sbagli!

La classe serializzabile deve implementare in metodi speciali writeObject/readObject e deve poter accedere in lettura/scrittura ai campi della super-classe, altrimenti la (de)serializzazione non potrebbe essere completa (i campi della super-classe avrebbero valori di default).

I campi, per essere accessibili dalla sotto-classe devono essere resi accessibili tramite metodi setter/getter oppure marcati protected, quale dei due modi, dipende dal design.

[robb7582]

Ma scusate una cosa se il serialUID non centra nulla con la versione della JVM perchè quando genero con la JVM 1.6 il serialUID di una classe è diverso da quello generato dalla JVM 1.4.02 sulla medesima classe?
Perchè a questo punto se io salvo i dati serializzati su file o su db con JVM 1.4.02 e poi quando ricompilo e rigenero l'UID con la 1.6 deserializzando lo stream serializzato salvato su file o db non mi dovrebbe dare errore, se il calcolo dell'UID fatto dalla 1.6 è diverso dalla 1.4.02?? E così anche se non lo metto cmq i due lo generano di default e dovrebbe accadere lo stesso?? a meno che di generarlo una volta sola e riusare lo stesso serialUID iniziale calcolato con JVM vecchia anche per la nuova JVM(senza farlo rigenerare dalla JVM nuova).. giusto?

Originariamente inviato da andbin
Se ti riferisci alla super-classe non serializzabile con costruttore no-arg, allora non sbagli!

La classe serializzabile deve implementare in metodi speciali writeObject/readObject e deve poter accedere in lettura/scrittura ai campi della super-classe, altrimenti la (de)serializzazione non potrebbe essere completa (i campi della super-classe avrebbero valori di default).

I campi, per essere accessibili dalla sotto-classe devono essere resi accessibili tramite metodi setter/getter oppure marcati protected, quale dei due modi, dipende dal design.