Was ist eine serialVersionUID und warum sollte ich sie verwenden?

Question

Eclipse gibt Warnungen aus, wenn ein serialVersionUID fehlt.

Die serialisierbare Klasse Foo deklariert keine statische finale serialVersionUID-Feld vom Typ long

¿Qué es? serialVersionUID und warum ist sie wichtig? Bitte zeigen Sie ein Beispiel, bei dem fehlende serialVersionUID wird ein Problem verursachen.

Answer 1

Was ist ein serialVersionUID und warum sollte ich es verwenden?

SerialVersionUID ist ein eindeutiger Bezeichner für jede Klasse, JVM verwendet es, um die Versionen der Klasse zu vergleichen und sicherzustellen, dass dieselbe Klasse, die bei der Serialisierung verwendet wurde, bei der Deserialisierung geladen wird.

Wenn Sie eine angeben, haben Sie mehr Kontrolle, obwohl die JVM eine generiert, wenn Sie sie nicht angeben. Der generierte Wert kann sich zwischen verschiedenen Compilern unterscheiden. Außerdem möchte man manchmal aus irgendeinem Grund die Deserialisierung von alten serialisierten Objekten verbieten [ backward incompatibility ], und in diesem Fall müssen Sie nur die serialVersionUID ändern.

Le site Javadocs für Serializable sagen :

die Standardberechnung der serialVersionUID ist sehr empfindlich gegenüber der Klasse Details, die je nach Compiler-Implementierung variieren können, und kann daher zu unerwarteten InvalidClassException s während Deserialisierung.

Daher müssen Sie serialVersionUID deklarieren, weil wir damit mehr Kontrolle haben .

Dieser Artikel hat einige gute Punkte zu diesem Thema.

Answer 2

In der ursprünglichen Frage wurde nach dem "Warum ist es wichtig" und dem "Beispiel" gefragt, wo dies Serial Version ID nützlich wäre. Nun, ich habe eine gefunden.

Angenommen, Sie erstellen eine Car Klasse, instanziiert sie und schreibt sie in einen Objektstrom. Das abgeflachte Auto-Objekt liegt eine Zeit lang im Dateisystem. In der Zwischenzeit, wenn die Car Klasse wird durch Hinzufügen eines neuen Feldes geändert. Wenn Sie später versuchen, die geglättete Klasse zu lesen (d.h. zu deserialisieren) Car Objekt, erhalten Sie die java.io.InvalidClassException - weil allen serialisierbaren Klassen automatisch ein eindeutiger Bezeichner zugewiesen wird. Diese Ausnahme wird ausgelöst, wenn der Bezeichner der Klasse nicht mit dem Bezeichner des reduzierten Objekts übereinstimmt. Wenn man genau darüber nachdenkt, wird die Ausnahme wegen der Hinzufügung des neuen Feldes ausgelöst. Sie können diese Ausnahme vermeiden, indem Sie die Versionierung selbst steuern, indem Sie eine explizite serialVersionUID deklarieren. Es gibt auch einen kleinen Leistungsvorteil durch die explizite Deklaration Ihrer serialVersionUID (denn es muss nicht berechnet werden). Daher ist es die beste Praxis, Ihre eigene serialVersionUID zu Ihren serialisierbaren Klassen hinzuzufügen, sobald Sie sie wie unten gezeigt erstellen:

public class Car {
    static final long serialVersionUID = 1L; //assign a long value
}

Answer 3

Zunächst muss ich erklären, was Serialisierung ist.

Serialisierung ermöglicht es, ein Objekt in einen Stream zu konvertieren, um dieses Objekt über das Netzwerk zu senden ODER in eine Datei zu speichern ODER in der DB für die Briefverwendung zu speichern.

Es gibt einige Regeln für die Serialisierung .

• Ein Objekt ist nur serialisierbar, wenn seine Klasse oder seine Oberklasse die Schnittstelle Serializable implementiert

• Ein Objekt ist serialisierbar (implementiert selbst die Schnittstelle Serializable), auch wenn seine Oberklasse dies nicht ist. Die erste Oberklasse in der Hierarchie der serialisierbaren Klasse, die die Schnittstelle Serializable nicht implementiert, MUSS jedoch einen No-Arg-Konstruktor haben. Wenn dies nicht der Fall ist, erzeugt readObject() zur Laufzeit eine java.io.InvalidClassException

• Alle primitiven Typen sind serialisierbar.

• Transiente Felder (mit transientem Modifikator) werden NICHT serialisiert (d. h. nicht gespeichert oder wiederhergestellt). Eine Klasse, die Serializable implementiert, muss transiente Felder von Klassen markieren, die keine Serialisierung unterstützen (z. B. ein Dateistrom).

• Statische Felder (mit statischem Modifikator) werden nicht serialisiert.

Wenn Object serialisiert wird, assoziiert Java Runtime die serielle Versionsnummer, auch bekannt als die serialVersionID .

Wo wir serialVersionID benötigen:

Während der Deserialisierung, um zu prüfen, ob Sender und Empfänger in Bezug auf die Serialisierung kompatibel sind. Wenn der Empfänger die Klasse mit einer anderen serialVersionID dann wird die Deserialisierung mit InvalidClassCastException .
Eine serialisierbare Klasse kann ihre eigene serialVersionUID explizit durch Deklaration eines Feldes namens serialVersionUID die statisch, endgültig und vom Typ long sein müssen.

Versuchen wir dies anhand eines Beispiels.

import java.io.Serializable;

public class Employee implements Serializable {
    private static final long serialVersionUID = 1L;
    private String empname;
    private byte empage;

    public String getEmpName() {
        return name;
    }

    public void setEmpName(String empname) {
        this.empname = empname;
    }

    public byte getEmpAge() {
        return empage;
    }

    public void setEmpAge(byte empage) {
        this.empage = empage;
    }

    public String whoIsThis() {
        return getEmpName() + " is " + getEmpAge() + "years old";
    }
}

Serialisierungsobjekt erstellen

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;

public class Writer {
    public static void main(String[] args) throws IOException {
        Employee employee = new Employee();
        employee.setEmpName("Jagdish");
        employee.setEmpAge((byte) 30);

        FileOutputStream fout = new
                FileOutputStream("/users/Jagdish.vala/employee.obj");
        ObjectOutputStream oos = new ObjectOutputStream(fout);
        oos.writeObject(employee);
        oos.close();
        System.out.println("Process complete");
    }
}

Das Objekt deserialisieren

import java.io.FileInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;

public class Reader {
    public static void main(String[] args) throws ClassNotFoundException, IOException {
        Employee employee = new Employee();
        FileInputStream fin = new FileInputStream("/users/Jagdish.vala/employee.obj");
        ObjectInputStream ois = new ObjectInputStream(fin);
        employee = (Employee) ois.readObject();
        ois.close();
        System.out.println(employee.whoIsThis());
    }
}

HINWEIS: Ändern Sie nun die serialVersionUID der Klasse Employee und speichern Sie:

private static final long serialVersionUID = 4L;

Und führen Sie die Klasse Reader aus. Wenn Sie die Writer-Klasse nicht ausführen, erhalten Sie die Ausnahme.

Exception in thread "main" java.io.InvalidClassException: 
com.jagdish.vala.java.serialVersion.Employee; local class incompatible: 
stream classdesc serialVersionUID = 1, local class serialVersionUID = 4
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:616)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1623)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at com.krishantha.sample.java.serialVersion.Reader.main(Reader.java:14)

Answer 4

Wenn Sie Ihre Objekte niemals in ein Byte-Array serialisieren und senden/speichern müssen, dann brauchen Sie sich darüber keine Gedanken zu machen. Wenn doch, dann müssen Sie Ihre serialVersionUID berücksichtigen, da der Deserialisierer des Objekts sie mit der Version des Objekts abgleichen wird, die sein Classloader hat. Lesen Sie mehr darüber in der Java Language Specification.

Answer 5

Wenn Sie diese Warnung bei einer Klasse erhalten, an deren Serialisierung Sie nie denken und die Sie nicht selbst deklariert haben implements Serializable ist, liegt es oft daran, dass Sie von einer Oberklasse geerbt haben, die Serializable implementiert. Oft wäre es dann besser, an ein solches Objekt zu delegieren, anstatt die Vererbung zu nutzen.

Also, statt

public class MyExample extends ArrayList<String> {

    public MyExample() {
        super();
    }
    ...
}

tun

public class MyExample {
    private List<String> myList;

    public MyExample() {
         this.myList = new ArrayList<String>();
    }
    ...
}

und rufen in den entsprechenden Methoden myList.foo() anstelle von this.foo() (oder super.foo() ). (Dies trifft nicht in allen Fällen zu, aber doch recht häufig.)

Ich sehe oft Leute, die JFrame oder ähnliches erweitern, obwohl sie eigentlich nur das hier delegieren müssen. (Dies hilft auch für die automatische Vervollständigung in einer IDE, da JFrame Hunderte von Methoden hat, die Sie nicht benötigen, wenn Sie Ihre benutzerdefinierten in Ihrer Klasse aufrufen möchten).

Ein Fall, in dem die Warnung (oder die serialVersionUID) unvermeidlich ist, ist, wenn Sie von AbstractAction erweitern, normalerweise in einer anonymen Klasse, nur das Hinzufügen der actionPerformed-Methode. Ich denke, dass es in diesem Fall keine Warnung geben sollte (da man normalerweise solche anonymen Klassen sowieso nicht zuverlässig über verschiedene Versionen der Klasse hinweg serialisieren und deserialisieren kann), aber ich bin mir nicht sicher, wie der Compiler dies erkennen könnte.