|
From: Michael <mj...@we...> - 2005-05-29 15:41:03
|
Hi, f=FCr das Speichern und Laden von Modellen habe ich im ersten Ansatz die=20 die Standard-Java-Serialisierung verwendet. Dabei ist mir Folgendes=20 aufgefallen: * Viel "implements Serializable" * Einige Attribute auf "transient" umgestellt * StackOverflowError bei Abspeichern des jmove-source-Modells Strukturell ist mir aufgefallen, dass unsere abgespeicherten Modelle=20 nicht transportf=E4hig sind, da assozierte Locations nach einem Laden=20 nicht an der gleichen Stelle liegen m=FC=DFen und somit Funktionalit=E4t=20 wie Source-Code-Edit nicht funktionieren.=20 Im Prinzip sehe ich 4 M=F6glichkeiten den Problemen zu begegnen: A. StackOverflow beheben: Schwierig, weil die Stelle nicht verraten=20 wird: ist es einfach die Menge oder erkennt der=20 Standard-Java-Mechanismus keine Zyklen? Warum funktioniert das=20 Abspeichern und Laden von Byte-Code-Modellen? B. Eigene Implementierung der Serialisierung: aufwendig aber=20 sicherlich passend C: Nutzung von XStream einer Bibliothek (250KB) zur Serialisierung:=20 einfach zu verwenden, aber erzeugte Datenvolumen =FCbersteigt=20 wesentlich die Standard-Java-Serialisierung (12MB statt 150KB f=FCr=20 Junit), gestiegene Memory-Anforderungen durch DOM-Ansatz=20 (Jmove-Source-Modell brach mit einer outOfMemory-Excpetion ab) D: Pseudo-Serialisierung: Serialisierung der Modulpfade und erneutes=20 Parsen beim Laden, wenig Aufwand aber schlechte Performanz Was denkt Ihr? Gru=DF Michael |