Il runtime Java ignora serialVersionUIDs?

Question

Devo lavorare con un gran numero di classi Java compilate che non hanno specificato esplicitamente un serialVersionUID. Poiché i loro UID sono stati generati arbitrariamente dal compilatore, molte delle classi che devono essere serializzate e deserializzate finiscono per causare eccezioni, anche se le definizioni delle classi effettive corrispondono. (Questo è tutto il comportamento previsto, ovviamente.)

Non è pratico per me tornare indietro e correggere tutto questo codice di terze parti.

Pertanto, la mia domanda è: c'è un modo per fare in modo che il runtime Java ignori differenze nei serialVersionUIDs e non riescano a deserializzare solo quando ci sono effettive differenze nella struttura?

Answer 1

Se hai accesso alla base di codice, puoi utilizzare l'attività SerialVer per Ant per inserire e modifica il serialVersionUID nel codice sorgente di una classe serializzabile e risolvi il problema una volta per tutte.

Se non puoi, o se questa non è un'opzione (ad esempio se hai già serializzato alcuni oggetti che devi deserializzare), una soluzione sarebbe quella di estendere ObjectInputStream . Aumenta il suo comportamento per confrontare il serialVersionUID del descrittore di flusso con il serialVersionUID della classe nella JVM locale che questo descrittore rappresenta e di utilizzare il descrittore di classe locale in caso di mancata corrispondenza . Quindi, basta usare questa classe personalizzata per la deserializzazione. Qualcosa del genere (crediti per questo messaggio ):

import java.io.IOException;
import java.io.InputStream;
import java.io.InvalidClassException;
import java.io.ObjectInputStream;
import java.io.ObjectStreamClass;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;


public class DecompressibleInputStream extends ObjectInputStream {

    private static Logger logger = LoggerFactory.getLogger(DecompressibleInputStream.class);

    public DecompressibleInputStream(InputStream in) throws IOException {
        super(in);
    }

    protected ObjectStreamClass readClassDescriptor() throws IOException, ClassNotFoundException {
        ObjectStreamClass resultClassDescriptor = super.readClassDescriptor(); // initially streams descriptor
        Class localClass; // the class in the local JVM that this descriptor represents.
        try {
            localClass = Class.forName(resultClassDescriptor.getName()); 
        } catch (ClassNotFoundException e) {
            logger.error("No local class for " + resultClassDescriptor.getName(), e);
            return resultClassDescriptor;
        }
        ObjectStreamClass localClassDescriptor = ObjectStreamClass.lookup(localClass);
        if (localClassDescriptor != null) { // only if class implements serializable
            final long localSUID = localClassDescriptor.getSerialVersionUID();
            final long streamSUID = resultClassDescriptor.getSerialVersionUID();
            if (streamSUID != localSUID) { // check for serialVersionUID mismatch.
                final StringBuffer s = new StringBuffer("Overriding serialized class version mismatch: ");
                s.append("local serialVersionUID = ").append(localSUID);
                s.append(" stream serialVersionUID = ").append(streamSUID);
                Exception e = new InvalidClassException(s.toString());
                logger.error("Potentially Fatal Deserialization Operation.", e);
                resultClassDescriptor = localClassDescriptor; // Use local class descriptor for deserialization
            }
        }
        return resultClassDescriptor;
    }
}

Answer 2

Quanto è poco pratico risolvere? Se hai il sorgente e puoi ricostruire, non puoi semplicemente eseguire uno script sull'intera base di codice per inserire un

private long serialVersionUID = 1L;

ovunque?

Answer 3

Utilizzare CGLIB per inserirli nelle classi binarie?

Answer 4

Gli errori di serializzazione in fase di esecuzione indicano esplicitamente quale dovrebbe essere l'ID. Basta cambiare le classi per dichiararle come ID e tutto andrà bene. Ciò implica che tu apporti delle modifiche, ma non credo che ciò possa essere evitato

Answer 5

È possibile utilizzare Aspectj per "introdurre" il campo in ogni classe serializzabile mentre viene caricato. Vorrei prima introdurre un'interfaccia marker in ogni classe usando il pacchetto e poi introdurrei il campo usando un hash del file di classe per serialVersionUID

public aspect SerializationIntroducerAspect {

   // introduce marker into each class in the org.simple package
   declare parents: (org.simple.*) implements SerialIdIntroduced;

   public interface SerialIdIntroduced{}

   // add the field to each class marked with the interface above.
   private long SerialIdIntroduced.serialVersionUID = createIdFromHash(); 

   private long SerialIdIntroduced.createIdFromHash()
   {
       if(serialVersionUID == 0)
       {
           serialVersionUID = getClass().hashCode();
       }
       return serialVersionUID;
   }
}

Dovrai aggiungere aspectj load time weaver agent alla VM in modo che possa intrecciare i consigli nelle classi di terze parti esistenti. È divertente anche se una volta che sei pronto a configurare Aspectj, è notevole il numero di usi che dovrai fare.

HTH

ste