Serialisierung: Laden von Objekten - Risiken?

[SimProtect]

Hallo Leute,

Ich habe eine Frage zur Verwendung des Interfaces Serializable.

Bisher haben wir serialisierbare Objekte ausschließlich für die Kommunikation zwischen Servern und Clients verwendet - also für Objekte, die direkt serialisiert und zeitnahe wieder deserialisiert werden.

Nun sollte ich in alle kürze ein kleines, internes Tool schreiben. Bestandteil dieses Tools ist es u.a., dass man das verwendete Objektnetz speichern und auch wieder laden kann.

Da ich keine Freigabe für die Verwendung von externen Bibliotheken habe, bin ich auf Java-Bordmittel angewiesen (Java Version 8 Update 51).

Die Serialisierung als XML kann leider nicht in frage, da ich dafür öffentliche, parameterloser Konstruktoren "hinterlegen" müsste, was die geforderte "Architektur" des Tools nicht gestattet.

Daher - und auch aus Zeitmangel - kam ich auf die Idee, die Objekt direkt zu serialisieren und in eine Datei zu pressen bzw. aus dieser Datei wieder zu deserialiseren.

Das funktioniert soweit tadellos (ich weiß, dass die API die Empfehlung ausspricht, man solle einen parameterlosen Konstruktor hinterlegen) und auch komplexe Objektnetze werden korrekt gespeichert und geladen.

Nun wurde mir jedoch die Befürchtung mitgeteilt, dass es damit Probleme geben könnte, wenn sich zwischen einem Speichern-Vorgang und einem Laden-Vorgang die JavaVersion ändern würde:

Bei uns ist das Problem, dass Java über ein zentrales Repository bereitgestellt wird. Also sowohl JRE, als auch JDK liegen an einer zentralen Stelle und werden auch zentral verwaltet. Wird also entschieden, dass wir eine andere Version verwenden, so ist diese Verwendung sofort wirksam. Die Verwendung einer eigenen JavaVersion ist nicht gestattet.

Jetzt ist meine Frage:
Kann folgende Situation eintreten?:
Ein Objektnetz wird in der Version A gespeichert und das Programm beendet. Java wird auf Version B geupdated; Nach einem Neustart kann das Objektnetz nicht mehr wiederhergestellt werden.

Entschuldigt bitte, wenn das eine blöde Frage ist - ich bin heute nicht wirklich auf der Höhe. Vielleicht habe ich daher auch eine naheliegendere Lösung einfach übersehen.

Beste Grüße

 

[stg]

Die De-/Serialisierung ist standardisiert, da wird es also normalerweise keine Probleme geben. Du kannst also eine jetzt mit Java Version X serialisierte Objekte auch mit Java Version Y wieder einlesen.
Probleme kann es geben, wenn sich die Implementierungen der serialisierten Objekte geändert hat, aber das liegt ja auf der Hand. Insbesondere musst du da aufpassen, wenn du "fremde" Klassen serialisierst, also z.B. irgendwelche Swing-Komponenten oder so. Ändert sich hier die Implementierung beim Java-Update, dann hast du ein Problem. Serialisierst du aber nur dein eigenes Data-Model, dann musst du dir keine Sorgen machen.

 

[nvidia]

[...]
Jetzt ist meine Frage:
Kann folgende Situation eintreten?:
Ein Objektnetz wird in der Version A gespeichert und das Programm beendet. Java wird auf Version B geupdated; Nach einem Neustart kann das Objektnetz nicht mehr wiederhergestellt werden.
[...]

Bzgl. der JDK eigenen Klassen sollte ein Versionsupdate die Serialisierung nicht torpedieren, es sei denn Oracle führt eine rückwärtsinkompatible Änderung an der Serialisierungsmaschinerie durch. Viel wichtiger ist es jedoch sich Gedanken darüber zu machen welche Änderungen an den Klassen dazu führen das diese auf einer der beteiligten Seite nicht mehr verarbeitet werden kann. Dazu gibt es hier https://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html aber genug Informationen.

 

[SimProtect]

Vielen Dank für die schnellen Antworten. Danke auch für den Link

 

[dayaftereh]

Hey, schau mal in Java 8 ist woll ne JSON API mit an Bord:

http://www.oracle.com/technetwork/articles/java/json-1973242.html

https://docs.oracle.com/javame/8.0/...json/package-summary.html#package_description