Gründe einer NotSerializableException herausfinden

[== != equals]

Guten Abend Sportsfreunde,

ich habe meine erste große Anwendung geschrieben, ein Kartenspiel mit Objekten wie Lobby, Tisch, Spieler, Kartengruppe usw.
Die Anwendung umfasst wegen den Spielregeln einiges an Code und läuft dennoch performant und ohne große Zwischenfälle.
Ab und zu treten jedoch kleine Fehler auf, die sehr schwer reproduzierbar sind. Da ich nun öfters stundenlang mit mehreren eigenen Testusern in verschiedenen Fenstern bestimmte Blattverläufe nachgespielt habe (auch nicht ganz einfach immer das jeweilige Guthaben, die Karten und Sitzpositionen aus dem Fehlerzeitpunkt zuzuweisen), möchte ich nun folgende Idee umsetzen:

Ich möchte bei bestimmten Spielfehlern und im Minutentakt die jeweilige Lobby (mit ihren Tischen und paar Spielern) serialisieren um dann bei Bedarf lokal bei mir sofort zum Fehlerzustand zu kommen.

Nun bekomme ich beim Schreiben des serialisierten Objekts die Meldung

java.io.NotSerializableException: Tisch

Kann gut sein, dass in dem Tisch oder seinem vererbten Objekten irgendwo z.B. ein Thread referenziert wird, der nicht serialisierbar ist, von dem ich vergessen habe ihn als transistent zu setzen. Aber wie finde ich heraus, was da genau fehlt? Die Exception bringt mir ja leider nur den Objektnamen. Muss ich selbst die Klasse Zeile für Zeile durchwühlen?

Wie finde ich heraus ob z.B. der ScheduledThreadPoolExecutor serialisiert werden kann, wenn er im zu serialisierenden Objekt gespeichert ist? Kann man das irgendwo in einer Doku nachsehen?

Und was sagt ihr generell zu meiner Idee? ^^

 

[Spacerat]

Was sagt denn der StackTrace der Fehlemeldung? Der ist immer sehr aufschlussreich, sofern man ihn (das klappt in 99 von 100 Fällen) bis zum eigenen Code zurückverfolgen kann.
Das ein oder andere Verhalten einer Klasse - z.B. Serialisierbarkeit - lassen sich meistens über kurze Testprogramme feststellen. Das gilt natürlich auch für diesen ScheduledThreadPoolExecuter. Eine weitere Möglichkeit besteht im hierarchischen Durchwälzen der Quellen (von Urklasse bis nach unten hin alle Interfaces und Super-Klassen abklappern) des SDK. Dort stellt man letztendlich fest, dass der ScheduledThreadPoolExecuter das Interface "Serializable" nicht implementiert, und damit auch nicht serialisierbar ist

 

[HoaX]

Der Meldung nach würde ich sagen dass der Tisch nicht serialisierbar ist.

 

[== != equals]

Was sagt denn der StackTrace der Fehlemeldung? Der ist immer sehr aufschlussreich, sofern man ihn (das klappt in 99 von 100 Fällen) bis zum eigenen Code zurückverfolgen kann.

Angehängt habe ich den Stack der Exception (das Forum hat das Bild ungefragt verkleinert). Die Methode setZug merkt dass z.B. eine Karte fehlt, diesen Zustand möchte ich durch die Klasse ContainerSerialisierung speichern und von dort aus geht es weiter in die Exception.
Wie kann ich nun durch den StackTrace mehr erfahren?

Das ein oder andere Verhalten einer Klasse - z.B. Serialisierbarkeit - lassen sich meistens über kurze Testprogramme feststellen. Das gilt natürlich auch für diesen ScheduledThreadPoolExecuter. Eine weitere Möglichkeit besteht im hierarchischen Durchwälzen der Quellen (von Urklasse bis nach unten hin alle Interfaces und Super-Klassen abklappern) des SDK.

Ja klar, aber dafür müsste ich dann ja sämtliche Klassen aller Referenzen und Erwähnungen durchgehen?

 

[Spacerat]

Wie kann ich nun durch den StackTrace mehr erfahren?

Dort stehen doch die Zeilennummern... z.B. würde ich jetzt einen in Zeile 14 der Klasse ContainerSerialisierung setzen, um zu erfahren, welcher Klasse das Objekt angehört, das dort serialisiert werden soll. Bin mir schon relativ sicher, dass es die Klasse "Tisch" ist. Selbst wenn diese Klasse "Serializable implementiert, so ist in dieser Hierarchie mindestens ein Attrribut vorhanden, welches das nicht ist, wie z.B. der besagte "ScheduledThreadPoolExecutor".

 

[Gelöschtes Mitglied 5909]

Alles was nicht java.io.Serializable implementiert ist nicht serialisierbar. Ein ThreadPool ist sicher nicht serializierbar

ScheduledThreadPoolExecutor (Java Platform SE 6)

da steht nix von implements Serializable.

Du solltest deine Objektstruktur überdenken

 

[== != equals]

Dort stehen doch die Zeilennummern... z.B. würde ich jetzt einen in Zeile 14 der Klasse ContainerSerialisierung setzen, um zu erfahren, welcher Klasse das Objekt angehört, das dort serialisiert werden soll. Bin mir schon relativ sicher, dass es die Klasse "Tisch" ist.

Ja okay habe vor lauter Bäumen nicht gesehen, dass in der Exception wirklich immer konkret das Objekt steht, das nicht serialisiert werden kann. Tisch war es in dem Fall, denn das wurde in dem zu serialisierenden Hauptobjekt Container referenziert. Danke schonmal bis hier.

Ich habe aber noch ein Problem: Ich habe nun zwar alle meine betroffenen Objekte als

Serializable

gekennzeichnet.
Nun scheiter ich aber an einem Objekt DataRow, das mir von dem Framework geliefert wird (SmartFoxServer, das liefert einem das komplette Sockethandling für die Clients). Die Klasse befindet sich scheinbar in einer .jar-Datei, ich habe sie in Libraries mit einem Build Path eingebunden.
Wie kann ich sie ebenfalls für die Serialisierung zulassen? Für mich gibt es keinen plausiblen Grund, sie nicht zuzulassen.

Ich habe testweise ein neues Objekt DataRowSerializeable gemacht, das von DataRow erbt, allerdings habe ich dann Probleme mit ClassCastException.

Alles was nicht java.io.Serializable implementiert ist nicht serialisierbar. Ein ThreadPool ist sicher nicht serializierbar

ScheduledThreadPoolExecutor (Java Platform SE 6)

da steht nix von implements Serializable.

Du solltest deine Objektstruktur überdenken

ThreadPool war ein von mir bewusst gewähltes Beispiel, um eben genau an solchen Klassen herauszufinden was serialisierbar ist und was nicht. Jetzt verstehe ich das inzwischen, dass man das erkennt wenn Serializable implementioert wird. Ein ThreadPool o.ä. nutze ich nicht in meinem Code. Ging nur um's Prinzip.

 

[Gelöschtes Mitglied 5909]

Mach dir einen Datencontainer und füll das nicht Serializierbare Objekt mit den Informationen nach dem Laden wieder.