Perché Java ha bisogno di un'interfaccia serializzabile?

Lavoriamo molto con la serializzazione e dover specificare un tag Serializable su ogni oggetto che utilizziamo è una specie di fardello. Soprattutto quando si tratta di una lezione di terze parti che non possiamo davvero cambiare.

La domanda è: poiché Serializable è un'interfaccia vuota e Java fornisce una solida serializzazione una volta aggiunta implements Serializable, perché non hanno reso tutto serializzabile e basta?

Cosa mi sto perdendo?

La serializzazione è piena di insidie. Il supporto della serializzazione automatica di questo modulo rende le parti interne della classe parte dell'API pubblica (motivo per cui javadoc fornisce le forme persistenti delle classi ).

Per la persistenza a lungo termine, la classe deve essere in grado di decodificare questo modulo, che limita le modifiche che è possibile apportare al design della classe. Questo rompe l'incapsulamento.

La serializzazione può anche portare a problemi di sicurezza. Essendo in grado di serializzare qualsiasi oggetto a cui ha un riferimento, una classe può accedere ai dati che normalmente non sarebbe in grado di (analizzando i dati byte risultanti).

Ci sono altri problemi, come la forma serializzata delle classi interne non ben definita.

Rendere serializzabili tutte le classi esacerberebbe questi problemi. Dai un'occhiata a Java Effective Second Edition , in particolare Item 74: Implement Serializable con giudizio .

Penso che entrambe le persone Java e .Net abbiano sbagliato questa volta, sarebbe stato meglio rendere tutto serializzabile per impostazione predefinita e invece è necessario contrassegnare solo quelle classi che non possono essere serializzate in modo sicuro.

Ad esempio in Smalltalk (un linguaggio creato negli anni '70) ogni oggetto è serializzabile per impostazione predefinita. Non ho idea del motivo per cui questo non sia il caso in Java, considerando il fatto che la stragrande maggioranza degli oggetti è sicura da serializzare e solo alcuni di essi non lo sono.

Contrassegnare un oggetto come serializzabile (con un'interfaccia) non rende magicamente quell'oggetto serializzabile, è stato sempre serializzabile , è solo che ora hai espresso qualcosa che il sistema avrebbe potuto trovare da solo, quindi non vedo una vera buona ragione per la serializzazione è così com'è ora.

Penso che sia stata una decisione sbagliata presa dai progettisti o la serializzazione fosse un ripensamento, o la piattaforma non era mai pronta per eseguire la serializzazione di default su tutti gli oggetti in modo sicuro e coerente.

Non tutto è realmente serializzabile. Prendi una connessione tramite presa di rete, ad esempio. Potresti serializzare i dati / lo stato del tuo oggetto socket, ma l'essenza di una connessione attiva andrebbe persa.

Il ruolo principale di Serializable in Java è quello di rendere effettivamente non serializzabili, per impostazione predefinita, tutti gli altri oggetti. La serializzazione è un meccanismo molto pericoloso, specialmente nella sua implementazione predefinita. Quindi, come l'amicizia in C ++, è disattivato per impostazione predefinita, anche se costa un po 'rendere le cose serializzabili.

La serializzazione aggiunge vincoli e potenziali problemi poiché la compatibilità della struttura non è assicurata. È positivo che sia disattivato per impostazione predefinita.

Devo ammettere che ho visto pochissime classi non banali in cui la serializzazione standard fa quello che voglio. Soprattutto nel caso di strutture dati complesse. Quindi lo sforzo che spenderesti per rendere la classe serializzabile correttamente riduce il costo dell'aggiunta dell'interfaccia.

Per alcune classi, specialmente quelle che rappresentano qualcosa di più fisico come un File, un Socket, un Thread o una connessione DB, non ha assolutamente senso serializzare le istanze. Per molti altri, la serializzazione può essere problematica perché distrugge i vincoli di unicità o semplicemente ti costringe a gestire istanze di diverse versioni di una classe, cosa che potresti non voler fare.

Probabilmente, sarebbe stato meglio rendere tutto Serializzabile per impostazione predefinita e rendere le classi non serializzabili tramite una parola chiave o un'interfaccia marker, ma poi, coloro che dovrebbero usare quell'opzione probabilmente non ci penserebbero. Così com'è, se devi implementare Serializable, ti verrà detto da un'eccezione.

Penso che il pensiero fosse quello di assicurarti che tu, come programmatore, sapessi che il tuo oggetto fosse serializzato.

Apparentemente tutto era serializzabile in alcuni progetti preliminari, ma per motivi di sicurezza e correttezza il progetto finale è finito come tutti sappiamo.

Fonte: perché le classi devono implementare Serializable per essere scritte su un ObjectOutputStream? .

Dovendo affermare esplicitamente che le istanze di una certa classe sono serializzabili, il linguaggio ti obbliga a pensare se dovresti permetterlo. Per semplici oggetti di valore la serializzazione è banale, ma nei casi più complessi è necessario riflettere davvero sulle cose.

Affidandoti semplicemente al supporto di serializzazione standard della JVM ti esponi a tutti i tipi di problemi di controllo delle versioni.

Unicità, riferimenti a risorse "reali", timer e molti altri tipi di artefatti NON sono candidati per la serializzazione.

Leggi questo per capire l'interfaccia Serializable e perché dovremmo rendere Serializzabili solo poche classi e inoltre dovremmo fare attenzione a dove usare la parola chiave transitoria nel caso in cui desideriamo rimuovere pochi campi dalla procedura di memorizzazione.

http://www.codingeek.com/java/io/object-streams-serialization-deserialization-java-example-serializable-interface/

Bene, la mia risposta è che questo non è per una buona ragione. E dai tuoi commenti posso vedere che l'hai già imparato. Altre lingue provano felicemente a serializzare tutto ciò che non salta su un albero dopo che hai contato fino a 10. Un oggetto dovrebbe essere serializzabile per impostazione predefinita.

Quindi, quello che devi fare fondamentalmente è leggere tu stesso tutte le proprietà della tua classe di terze parti. Oppure, se questa è un'opzione per te: decompila, metti lì la dannata parola chiave e ricompila.

Ci sono alcune cose in Java che semplicemente non possono essere serializzate perché sono specifiche del runtime. Cose come stream, thread, runtime, ecc. E anche alcune classi GUI (che sono connesse al sistema operativo sottostante) non possono essere serializzate.

Anche se sono d'accordo con i punti esposti in altre risposte qui, il vero problema è con la deserializzazione: se la definizione di classe cambia, c'è il rischio reale che la deserializzazione non funzioni. Non modificare mai i campi esistenti è un impegno piuttosto importante per l'autore di una libreria! Mantenere la compatibilità API è già un lavoro ingrato.

Una classe che deve essere mantenuta su un file o su un altro supporto deve implementare l'interfaccia Serializable, in modo che JVM possa consentire la serializzazione dell'oggetto classe. Perché la classe Object non è serializzata, nessuna delle classi ha bisogno di implementare l'interfaccia, dopotutto JVM serializza la classe solo quando uso ObjectOutputStream, il che significa che il controllo è ancora nelle mie mani per consentire alla JVM di serializzare.

Il motivo per cui la classe Object non è serializzabile per impostazione predefinita è il fatto che la versione della classe è il problema principale. Pertanto ogni classe interessata alla serializzazione deve essere contrassegnata come Serializable in modo esplicito e fornire un numero di versione serialVersionUID.

Se serialVersionUID non viene fornito, si ottengono risultati imprevisti durante la deserializzazione dell'oggetto, motivo per cui JVM lancia InvalidClassException se serialVersionUID non corrisponde. Pertanto ogni classe deve implementare l' interfaccia Serializable e fornire serialVersionUID per assicurarsi che la classe presentata ad entrambe le estremità sia identica.