Object nach Deserialisierung nicht mehr gleich

[woezelmann]

Hallo Leute,

ich hab folgendes Problem: Hab ne ziemlich komplizierten Map, die ungefähr so aussieht:

Map<String, Map<String, EcmObject>>

EcmObject enthält wiederrum einige Strings, ints und enums und eine Liste von anderen 'custom' Objecten.
Alles was ich so benutze implementiert Serializable und ich hab auch alle hashCode und equals Methoden überschrieben.

Wenn ich jetzt zwei unterschiedliche Instanzen dieses Konstrukts erstelle, die die gleichen Werte haben und sie mit equals() vergleiche, krieg ich ein TRUE zurück. Wenn ich jetzt aber ein Instanz auf die Palatte serialisiere und dann wieder deserialisiere, krieg ich plötzlich FALSE.

Jetzt stellt sich mir die Frage: wieso?

Irgendwelche Ideen?

Im voraus besten Dank!

 

[Atze]

haben alle klassen ne explizite serialVersionUID? ist nur ne vermutung, weiß nicht obs daran liegen könnte.

"If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification."

Quelle: Serializable (Java 2 Platform SE 5.0)

vielleicht kommt er da durcheinander, falls das beim equals mit einbezogen wird. irgendwei, keine ahnung ob das der knackpunkt sein könnte.

 

[fastjack]

Normalerweise müßtest Du dann eine SerializationException bekommen, wegen verschiedener SUIDs. Ich schätze mal das False kommt aus einem späteren equals ? Ein Problem kann natürlich sein, daß bei handgesetzer (und nicht ordentlich gepflegter) SUID Probleme entstehen, weil die abgespeicherten Daten verändert sind. (Beispiel: auf wenn auf immer und ewig 1L benutzt wird)

 

[SlaterB]

einfach vollständiges TestProgramm, schon sind alle Rätsel beendet,
EcmObject dabei zusammenkürzen auf 20 Zeilen

benutze die clone-Methode aus
Deep-Copy von Java-Objekten Der Informatik Student

wenn es damit klappt und mit anderem Code nicht, dann poste den anderen Code

 

[woezelmann]

@SlaterB

bin mir nicht ganz sicher ob ich dich verstehe, was meinst du. EcmObject auf 20 Zeilen zusammenkürzen?
Hab es mal mit der Deep-Copy versucht, das geklonte Object ist wieder NICHT equal!

 

[SlaterB]

na mein erster Satz ist doch 'vollständiges TestProgramm', also hier posten,
und da ist es dann wenig hilfreich wenn die Klasse EcmObject unbekannt bleibt oder 300 Zeilen lang ist und auf 5 weitere unbekannte Klassen verweist,

verwende eine möglichst kurze Dummy-Klasse, vielleicht nur mit einem Attribut,
wenn dann der Test gelingt, dann eben nach und nach mehr vom Ursprungscode einfügen,
auf diese Weise kannst du den Fehler übrigens auch ganz gut selber finden

eine andere Strategie ohne hier was zu posten wäre, sich die Objekte genauer anzuschauen!
nur equals == false ist ja nicht der Weisheit letzter Schluss, schaue dir die Anzahl der Objekte in jeder Map an, vergleiche diese einzeln bis auf die letzten String- und int-Variablen runter

ist es überhaupt normal, dass die Objekte gleich sind? auf zwei identische trifft es sicher zu,
aber wenn du in deinem Programm zweimal auf gleiche Weise das Objekt erzeugst, ist dann vielleicht equals auch schon false?

Map m1 = buildUpNewMapWithManyObjects();
Map m2 = buildUpNewMapWithManyObjects();
m1.equals(m2)

jede beteiligte Klasse mit nicht-überschriebener equals-Methode, unsortierter Liste, Zufallsgenerator im Konstruktor oder wer weiß was alles kann zu Unterschieden führen,
ein Objekt mit sich selber zu vergleichen bringt gar nix, das sollte IMMER true sein,
für eine exakte Kopie muss das nicht gelten

edit:
> Wenn ich jetzt zwei unterschiedliche Instanzen dieses Konstrukts erstelle,
ok..

 

[fastjack]

Schau doch mal, was an EcmObject nicht equals ist... Gibt es vielleicht transiente Felder, die dort verglichen werden ?

 

[JohannisderKaeufer]

Serialisiere und Deserialisiere doch mal beide Objekte, und vergleiche sie danach miteinander!

Bin gespannt was da rauskommt.

Und Serialisiere ein Objekt zwei mal und vergleiche es dann mit einem einmal serialisierten Objekt.

Mit etwas Logik läßt sich dann vielleicht der ein oder andere Schluß ziehen

 

[woezelmann]

Da bin ich wieder, hatte gestern keinen Nerv mehr, mich damit auseinanderzusetzen.

Hab jetzt bei einem Beispiel rausgefunden, worin sich die Instanzen unterscheiden. Zum besseren Verständnis hier eine kurze (@SlaterB: nicht mehr als 20 Zeilen lange, jetzt hab ichs geschnallt ) Zusammenfassung meiner Klassen:

public class EcmObject implements Comparable, Serializable {
    private EcmObjectType type;
    private String name;
    private List<EcmField> fields;
    private boolean pages;

    // getter, setter, equals, hashCode
}

public enum EcmObjectType implements Serializable {
    FOLDER, REGISTER, DOCUMENT
}

public class EcmField implements Comparable, Serializable {
    private EcmFieldDataType dataType;
    private EcmFieldControlType controlType;
    private String name;
    private String dbname;
    private String internalname;
    private Integer length;

    // getter, setter, equals, hashCode
}

public enum EcmFieldControlType implements Serializable{
    DEFAULT, CHECKBOX, LIST, DBLIST, TEXTAREA, HIERARCHY, TREE, GRID, RADIO, PAGECONTROL, STATIC;
}

public enum EcmFieldDataType implements Serializable {
    TEXT, DATE, NUMBER, GROUP, DEC;
}

Beim serialisieren verschwindet in meinem Beispiel aus im EcmObject aus der List<EcmField> fields (is ne LinkedList) ein Eintrag (an vorletzer Stelle; vor dem Serialisieren hat die Liste 31 Einträge, danach nur 30).

Das EcmField das verschwindet, sieht so aus:

EcmFieldDataType dataType = TEXT
EcmFieldControlType controlType = STATIC
String name = "Tätigkeiten exportieren"
String dbname = ""
String internalname = "B_TEXP"
Integer length -1

Dachte zuerst es könnte an dem Umlaut bei "Tätigkeiten exportieren" liegen, aber andere Einträge mit Umlauten werden scheinbar serialisiert.

Irgendwelche Ideen?

 

[SlaterB]

und wenn vorher nur 30 drin sind, sind es danach immer noch 30 oder 29?
wie sieht es bei 20, 10, vielleicht nur 2 oder 1 Objekten aus?

es fehlt immer noch die main-Methode für Copy, Paste, Run -> Fehler

ich könnte jetzt ein Testprogramm zusammenbasteln mit 30 beliebigen Einträgen und als 31. dann ungefähr den angegebenen,
aber ich glaube nicht daran dass es schiefgeht, daher spare ich mir doch die Mühe

 

[woezelmann]

Yeah, ich hab rausgefunden, woran es lag... Festhalten:

Was ich nicht erwähnt habe (erschien mir unwichtig) ist, dass ich beim Serialisieren in einem Schlag in die selbe Datei noch eine ListOrderedMap<String, Mapping> schreibe (ListOrderedMap ist so ein Konstrukt von Commons Collection).

Die Mapping Klasse sieht so aus:

public class Mapping implements Serializable {
    private EcmObjectType type;
    private String fromName = "";
    private String toName = "";
    private Map<String, String> fields = new ListOrderedMap<String, String>();
}

Wobei der EcmObjectType der gleiche enum ist, denn ich auch bei EcmObject benutze.

Wenn diese ListOrderedMap<String, Mapping> leer ist, dann ist equals auch equals. Sobald die ListOrderedMap<String, Mapping> Einträge hat, geht was schief.

Ich versteh zwar nicht wirklich, wieso, aber immerhin weiß ich jetzt was ich ändern muss...

 

[SlaterB]

> dass ich beim Serialisieren in einem Schlag in die selbe Datei

das passt ja kaum zur oben von mir erwähnten clone-Methode statt normaler Serialisierung


ganz schön gefährlich jetzt einfach so weiterzumachen wenn es in einer bestimmten Situation klappt..

 

[woezelmann]

benutze die clone-Methode aus
Deep-Copy von Java-Objekten Der Informatik Student

Was das angeht, hat ja auch nicht gefunzt, das hab ich gestern schon hingekriegt, lang irgendwie an einem int im EcmField. Hab dann auf Integer geändert und dann ging des.

edit: ist mir auch eingefallen

 

[fastjack]

Vielleicht liegts dann ja an der equals-Methode der Mappings ...