Menu
▾
▴
jmove-devel
|
From: <ax...@sp...> - 2005-05-30 09:31:36
|
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 > |
|
From: Michael <mj...@we...> - 2005-05-30 18:40:20
|
Hi Axel, grunds=C3=A4tzlich teile ich deine Pr=C3=A4ferenzen f=C3=BCr B und D. Aufgr= und=20 unserer Planungen w=C3=BCrde ich allerdings das aufwand=C3=A4rmere D=20 bevorzugen. Die Idee "Projektdatei" finde ich klasse, denn dadurch=20 wird nichts vorgegaukelt. Mein Vorschlag f=C3=BCr die konkrete Benennung: * load/save module compilation * load/save module set Wir sollten unser Men=C3=BCstruktur daf=C3=BCr weiter standardisieren. Wie = w=C3=A4re=20 es mit=20 Model New Add module ----------------- Load module compilation Save module compilation ----------------- Export XMI ----------------- Quit View Search types //Create diagram //Create report =09 Help Contents About Bzgl. der mittelfristigen Variante B w=C3=BCrde ich in der Tat ein=20 textbasierte Format (gerne XML) verwenden, dann sind Fehler leichter=20 nachvollziehbar und mit entsprechender Komprimierung sollte auch=20 Speicherplatz weniger ein Problem sein. Prinzipiell halte ich XMI f=C3=BCr= =20 zu =C3=BCberfrachtet, unser schmales Kernmodell bietet sicherlich eine=20 effizientere Serialisierungsm=C3=B6glichkeit. Allerdings wenn wir auch=20 Diagramme ablegen wollen... Apropos Diagramme: Es w=C3=A4re super, wenn man Diagramme selbst best=C3=BC= cken=20 k=C3=B6nnte: neues Diagramm anlegen, Packages in das Diagramm ziehen,=20 Abh=C3=A4ngigkeiten werden eingetragen, das Diagramm kann gedruckt=20 werden....megacool! ;-) Gru=C3=9F Michael Am Montag, 30. Mai 2005 11:31 schrieb ax...@sp...: > Hi Michael, > > da bist du aber wieder mal fleissig gewesen :-). Ich habe zumindest > etwas Zeit gefunden deine Sachen auszubrobieren. Den Stack-Overflow > habe ich allerdings noch nicht gefunden - nun ist es aber doch > raus... ;-) > > >Hi, > > > >f=C3=BCr das Speichern und Laden von Modellen habe ich im ersten Ansatz > > die die Standard-Java-Serialisierung verwendet. Dabei ist mir > > Folgendes aufgefallen: > > > >* Viel "implements Serializable" > >* Einige Attribute auf "transient" umgestellt > >* StackOverflowError bei Abspeichern des jmove-source-Modells > > > >Strukturell ist mir aufgefallen, dass unsere abgespeicherten > > Modelle nicht transportf=C3=A4hig sind, da assozierte Locations nach > > einem Laden nicht an der gleichen Stelle liegen m=C3=BC=C3=9Fen und som= it > > Funktionalit=C3=A4t wie Source-Code-Edit nicht funktionieren. > > > >Im Prinzip sehe ich 4 M=C3=B6glichkeiten den Problemen zu begegnen: > > > >A. StackOverflow beheben: Schwierig, weil die Stelle nicht > > verraten wird: ist es einfach die Menge oder erkennt der > >Standard-Java-Mechanismus keine Zyklen? Warum funktioniert das > >Abspeichern und Laden von Byte-Code-Modellen? > > > >B. Eigene Implementierung der Serialisierung: aufwendig aber > >sicherlich passend > > > >C: Nutzung von XStream einer Bibliothek (250KB) zur > > Serialisierung: einfach zu verwenden, aber erzeugte Datenvolumen > > =C3=BCbersteigt wesentlich die Standard-Java-Serialisierung (12MB > > statt 150KB f=C3=BCr Junit), gestiegene Memory-Anforderungen durch > > DOM-Ansatz > >(Jmove-Source-Modell brach mit einer outOfMemory-Excpetion ab) > > > >D: Pseudo-Serialisierung: Serialisierung der Modulpfade und > > erneutes 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 > hin und her =C3=BCberlegt und stelle mir das ungef=C3=A4hr so vor: > > - serialisierte Modellinformationen sind immer dann sinnvoll, wenn > jemand Zeit sparen m=C3=B6chte und Aktualit=C3=A4t nachrangig ist. Beisp= iel: > jemand untersucht einen Release-Stand oder mit jedem Build wird ein > serialisiertes (vorverdautes) Modell erzeugt. > > - wenn Aktualit=C3=A4t im Vordergrund steht, dann arbeite ich lieber auf > dem Source- oder Bytecode. > > - In einem Modell kann es Teile geben, die sich h=C3=A4ufig =C3=A4ndern u= nd > Teile die sich seltener =C3=A4ndern. Man ist also mit unterschiedlichen > Anforderungen an die Aktualit=C3=A4t konfrontiert. > > Ausgehend von dieser Betrachtung kann ich mir folgende L=C3=B6sung > vorstellen: > > - Eine Modelldatei enth=C3=A4lt nur die Modulpfade - also D. Ich w=C3=BC= rde > dies jedoch nicht als Pseudo-Serialisierung bezeichnen. Es ist eher > mit einer Projektdatei einer IDE vergleichbar. > > - ein serialisiertes Modell kann genauso als Modul betrachtet > werden wie ein Source-/Bytecode - Jar/Verzeichnis. Es handelt sich > also nur um eine andere Modulform (und w=C3=BCrde evtl. einen eigenen > Loader erfordern) . > > - es gibt Mechanismen um ein beliebiges Modul in ein serialisiertes > Modul umzuwandeln. > > - Source-(Byte-)Code-Modul + serialisiertes Modul + > Synchronisierung k=C3=B6nnte ein "cached module" sein. > > - wie k=C3=B6nnte man "serialisiertes Modul" nur sinnvollerweise > nennen?!? > > 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=BCnde gibt. Somit w=C3=BCrde A aussen vor sein. C w=C3=BCrde auch n= icht so > recht in die Betrachtung passen, da meine Annahmen ja davon > ausgehen, dass man Zeit und Speicherplatz sparen m=C3=B6chte. > Grunds=C3=A4tzlich habe ich nichts gegen textbasierte Formate wenn sie > die Anforderung grunds=C3=A4tzlich erf=C3=BCllen. Ein XML-basiertes Format > kann einem sicherlich die Implementierung erleichtern, wenn es > allerdings dadurch zu geschw=C3=A4tzig wird nutzt uns das auch nichts. > Ansonsten k=C3=B6nnten wir keine weiteren grunds=C3=A4tzlichen Vorteile a= us > einem XML-Format ziehen. Speziell ein XMI-Modul w=C3=A4re zwar auch sehr > attraktiv, w=C3=BCrde uns aber im Rahmen dieser Diskussion nicht weiter > bringen. > > 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-q22005 > > _______________________________________________ > >Jmove-devel mailing list > >Jmo...@li... > >https://lists.sourceforge.net/lists/listinfo/jmove-devel > > ------------------------------------------------------- > 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-q22005 > _______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel |
Thanks for helping keep SourceForge clean.
X