Re: [Jmove-devel] ModelSerialization

[<ax...@sp...>]

Hi Michael,=20

da bist du aber wieder mal fleissig gewesen :-). Ich habe zumindest etwas Z=
eit gefunden deine Sachen auszubrobieren. Den Stack-Overflow habe ich aller=
dings noch nicht gefunden - nun ist es aber doch raus... ;-)


>Hi,
>
>f=C3=BCr das Speichern und Laden von Modellen habe ich im ersten Ansatz di=
e=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=C3=A4hig sind, da assozierte Locations nach einem Laden=
=20
>nicht an der gleichen Stelle liegen m=C3=BC=C3=9Fen und somit Funktionalit=
=C3=A4t=20
>wie Source-Code-Edit nicht funktionieren.=20
>
>Im Prinzip sehe ich 4 M=C3=B6glichkeiten 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 =C3=BCbersteigt=20
>wesentlich die Standard-Java-Serialisierung (12MB statt 150KB f=C3=BCr=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?

Also ich denke B + D oder D + B w=C3=A4re Klasse.  Ich habe ein bisschen hi=
n und her =C3=BCberlegt und stelle mir das ungef=C3=A4hr so vor:

- serialisierte Modellinformationen sind immer dann sinnvoll, wenn jemand Z=
eit sparen m=C3=B6chte und Aktualit=C3=A4t nachrangig ist.  Beispiel: jeman=
d untersucht einen Release-Stand oder mit jedem Build wird ein serialisiert=
es (vorverdautes) Modell erzeugt.

- wenn Aktualit=C3=A4t im Vordergrund steht, dann arbeite ich lieber auf de=
m Source- oder Bytecode.

- In einem Modell kann es Teile geben, die sich h=C3=A4ufig =C3=A4ndern und=
 Teile die sich seltener =C3=A4ndern. Man ist also mit unterschiedlichen An=
forderungen an die Aktualit=C3=A4t konfrontiert.

Ausgehend von dieser Betrachtung kann ich mir folgende L=C3=B6sung vorstell=
en:

- Eine Modelldatei enth=C3=A4lt nur die Modulpfade -  also D. Ich w=C3=BCrd=
e dies jedoch nicht als Pseudo-Serialisierung bezeichnen. Es ist eher mit e=
iner Projektdatei einer IDE vergleichbar.

- ein serialisiertes Modell kann genauso als Modul betrachtet werden wie ei=
n Source-/Bytecode - Jar/Verzeichnis. Es handelt sich also nur um eine ande=
re Modulform  (und w=C3=BCrde evtl. einen eigenen Loader erfordern) .=20

- es gibt Mechanismen um ein beliebiges Modul in ein serialisiertes Modul u=
mzuwandeln.

- Source-(Byte-)Code-Modul + serialisiertes Modul + Synchronisierung k=C3=
=B6nnte ein "cached module" sein.

- wie k=C3=B6nnte man "serialisiertes Modul" nur sinnvollerweise nennen?!?=
=20

Die Beschr=C3=A4nkung auf die Modulebene macht sicherlich die Anwendung von=
 B notwendig, f=C3=BCr das es offensichtlich ja auch noch andere Gr=C3=BCnd=
e gibt. Somit w=C3=BCrde A aussen vor sein. C w=C3=BCrde auch nicht so rech=
t in die Betrachtung passen, da meine Annahmen ja davon ausgehen, dass man =
Zeit und Speicherplatz sparen m=C3=B6chte. Grunds=C3=A4tzlich habe ich nich=
ts gegen textbasierte Formate wenn sie die Anforderung grunds=C3=A4tzlich e=
rf=C3=BCllen. Ein XML-basiertes Format kann einem sicherlich die Implementi=
erung erleichtern, wenn es allerdings dadurch zu geschw=C3=A4tzig wird nutz=
t uns das auch nichts. Ansonsten k=C3=B6nnten wir keine weiteren grunds=C3=
=A4tzlichen Vorteile aus einem XML-Format ziehen. Speziell ein XMI-Modul w=
=C3=A4re zwar auch sehr attraktiv, w=C3=BCrde uns aber im Rahmen dieser Dis=
kussion nicht weiter bringen.=20

Ok -  das reicht erst mal. Was meint ihr dazu?

Ahoi

Axel


>
>
>Gru=C3=9F
>Michael
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Yahoo.
>Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
>Search APIs Find out how you can build Yahoo! directly into your own
>Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q220=
05
>_______________________________________________
>Jmove-devel mailing list
>Jmo...@li...
>https://lists.sourceforge.net/lists/listinfo/jmove-devel
>