# Allgemeine Frage zu Grafikfähigkeiten von Java



## hutzlibu (2. Feb 2011)

Hallo Javagemeinde,

ich hätte da mal eine allgemeine Frage bezüglich den Fähigkeiten von Java, was Grafik und Interaktivität angeht.
Nun komme ich selbst ja aus der bunten Welt von Flash, aber da mich Adobes Eigentümerschaft an Flash schon immer gestört hat und ich davon irgendwann mal loskommen wollte, sehe mich nun gerade nach einer geeigneten Alternative um. 
Das ich Abstriche machen muss, ist mir klar, da Adobe nicht umsonst Marktführer auf dem Gebiet ist, aber ich will mich auch nicht verrenken müssen, für (in meinen Augen) einfache Anforderungen.

Was ich zum Beispiel prinzipiell machen will, ist folgendes:



erstellen eines Grafikobjektes/Containers, etwa ein roter Kreis


anzeigen des Kreises auf der Bühne


registrieren eines Mausklick Eventlisteners, der wenn der Kreis angeklickt wurde, eine bestimmte Funktion aufruft

Das das prinzipiell möglich ist, nehme ich wohl an, was mich nur interessiert, ist die Frage der Komplexität, also wie viel Aufwand ich betreiben müsste, um das gewünschte Ergebnis zu erreichen.

In Flash wäre das alles mit ein paar Zeilen Code erledigt, folgender Code etwa wäre ein vollständig lauffähiges Flashprogramm :


```
package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;		
	public class FlashCap extends Sprite
	{
		public function FlashCap()
		{			
			// erzeugt einen neuen Anzeigecontainer
			var kreis:Sprite = new Sprite();
			// zeichnet einen kreis in den container
			kreis.graphics.beginFill(0xff0000); // farbe rot
			kreis.graphics.drawEllipse(0,0, 300, 300);  // x:0  y:0  breite: 300 höhe: 300
					
			// fügt den Kreis der Bühne hinzu und zeigt ihn so auf dem Bildschirm an
			this.addChild(kreis);
			
			// registriert einen eventlistener, der jedesmal wenn der kreis mit der maus angeklickt wird, die Funktion kreisAngeklickt aufruft 
			kreis.addEventListener(MouseEvent.CLICK, kreisAngeklickt);
			
			function kreisAngeklickt(e:MouseEvent):void{				
				trace("Der Kreis wurde angeklickt!"); // wird auf der konsole ausgegeben
			}
		}		
	}
}
```

Könnte mich hier freundlicherweise jemand darüber aufklären, auf was ich mich einstellen muss, wenn ich das in Java umsetzen wöllte?
Oder könnte jemand vielleicht sogar den entsprechenden Code posten?

Wenn mir jemand helfen könnte, wäre ich sehr dankbar und ihr hättet der Java-Community damit womöglich ein neues Mitglied beschert :bae:


----------



## slawaweis (2. Feb 2011)

hutzlibu hat gesagt.:


> Was ich zum Beispiel prinzipiell machen will, ist folgendes:
> 
> 
> 
> ...



das geht alles in Java, würde aber 2-3 Mal mehr Quelltext erfordern oder ein zusätzliches Framework. Flash war von Anfang an für interaktive Grafiken ausgelegt, Java ist da universeller. Die Frage ist nur, ob Du Desktop-Anwendungen planst oder fürs Web. Für letzteres wäre HTML5, JavaScript und SVG besser geeignet, mit einem eventuellen Backend (Server-Seite) in Java.

Hier eine Reihe von Beispielen, wie es in Java gehen kann:

2D Graphics GUIJava

Slawa


----------



## Marco13 (2. Feb 2011)

Auf meiner TODO-Liste ist schon seeeehhhr sehr lange (aber trotzdem recht weit unten, weil nicht wirklich "dringend" oder "wichtig") ein Punkt dazu: Eine Auflistung von Mini-Grundgerüsten für Swing-Anwendungen für die FAQ. Ganz bewußt KEINE Tutorials, sondern nur Copy&Paste-Beispiele für verschiedene Anforderungen, die immer wieder mal angefragt werden. Und was du beschrieben hast, wäre EINE solche Anforderung. Das wäre dann unterteilt:
- Einfach etwas zeichnen
- Etwas anklickbares zeichnen
- Etwas anklick- und verschiebbares zeichnen

Daran wird vielleicht schon deutlich: Das ist ein bißchen schwer zu vergleichen. Der Aufwand für den beschriebenen Code würde sich in Grenzen halten. Aber ich schätze, dass man bei dem Flash-Beispiel jetzt sowas wie
sprite.setDraggable(true);
machen kann, und schon kann man den Kreis in der Gegend rumziehen, und mit sowas wie
sprite.doSomeFancyAnimation();
passiert irgendwas anderes hübsches buntes. Dafür ist Flash eben da.

Das kann man nicht direkt nach Java übertragen. Java ist in diesem Sinne einfach VIEL low-leveliger. Man kann eben Dinge machen, die mit Flash nicht oder nur schwer gehen, allerdings ist es (plakativ gesagt) "mehr zu schreiben". Wenn man etwas komplexeres plant, würde man sich erst überlegen, was genau gehen soll, und sich dann das entsprechende Grundgerüst dafür bauen. D.h. man könnte genau das, was du jetzt dort in 15 Zeilen Flash geschrieben hast, auch mit 15 Zeilen Java schreiben - WENN man sich erstmal 100-200 Zeilen "Gerüstklassen" wie "Sprite", "Stage" usw. gebaut hat. Und wenn man mit OpenGL soft shadows auf Basis von Spherical Harmonics berechnen will um Bilder zu rendern, die man JPG-Komprimiert über RMI verschicken und in einer SQL-Datenbank speichern will, dann sind es eben ein paar tausend Zeilen mehr, aber es geht  

Vielleicht suchst zu eher sowas wie JavaFX | Rich Internet Applications Development | RIAs Java FX oder Processing.org ?


----------



## L-ectron-X (2. Feb 2011)

Marco13 hat gesagt.:


> Eine Auflistung von Mini-Grundgerüsten für Swing-Anwendungen für die FAQ. Ganz bewußt KEINE Tutorials, sondern nur Copy&Paste-Beispiele für verschiedene Anforderungen, die immer wieder mal angefragt werden.


Klingt gut, da sollten wir (sofern du magst) an anderer Stelle noch mal drüber reden und was auf die Beine stellen!


----------



## hutzlibu (2. Feb 2011)

Danke für die Antworten, ich hätte mich aber vielleicht etwas präziser ausdrücken sollen.
Und zwar was ich (unter anderem) machen möchte, ist eine Desktopapplikation, wo recht viele Daten automatisiert Visualisiert werden sollen - und diese Visualisierungen sollen dann auch auswählbar sein.

Und das Ganze soll dann möglichst Plattformunabhängig und auf jeden Fall OpenSource sein. 

JavaFX fällt da also aus, da ich da auch bei Flash bleiben könnte. ueh:



> bei dem Flash-Beispiel jetzt sowas wie
> sprite.setDraggable(true);
> machen kann, und schon kann man den Kreis in der Gegend rumziehen


Dragging geht in Flash übrigens tatsächlich so einfach mit 
kreis.startDrag(); :toll:
Und das es sowas Nativ in Java nicht gibt, wusste ich eigentlich auch schon.

Was ich also eigentlich hören wollte, war ...


> D.h. man könnte genau das, was du jetzt dort in 15 Zeilen Flash geschrieben hast, auch mit 15 Zeilen Java schreiben - WENN man sich erstmal 100-200 Zeilen "Gerüstklassen" wie "Sprite", "Stage" usw. gebaut hat.


... das sich jemand bereits die Mühe gemacht und ein ähnliches Framework aufgebaut hat und es frei zum Download auf der Webseite XYZ anbietet :toll:

Offenbar hat das aber noch keiner gemacht, bzw. die die es gemacht haben, haben ihr Wissen für sich behalten?
Und um die Gerüstklassen selber zu schreiben, fehlt mir glaube ich die Zeit und die Motivation, da man sich ja dann tiefer mit den Eigenarten der Lowlevel Java Grafik auseinandersetzen müsste - eben das, was ich vermeiden will :bae:


----------



## Marco13 (2. Feb 2011)

L-ectron-X hat gesagt.:


> Klingt gut, da sollten wir (sofern du magst) an anderer Stelle noch mal drüber reden und was auf die Beine stellen!



Hab mal einen Thread (noch ohne Code) aufgemacht: http://www.java-forum.org/entwuerfe/113007-kein-swing-tutorial.html#post726687 . Mal schauen ob ich am Wochenende das wieder vorkrame, was ich bisher gemacht hatte (und inwiweit ich das noch für sinnvoll halte - ist schon ewig her, dass ich das mal angefangen hatte...  )


----------



## Wildcard (2. Feb 2011)

> Und zwar was ich (unter anderem) machen möchte, ist eine Desktopapplikation, wo recht viele Daten automatisiert Visualisiert werden sollen - und diese Visualisierungen sollen dann auch auswählbar sein.


Geht es vielleicht um eine Graph ähnliche Visualisierung?
Da gibt es dann schon ziemlich viel fertiges.
Mein Liebling für einfache Dinge ist Zest.
Gibt aber jede Menge weiterer Möglichkeiten wie Visual Library, Draw2D, Graphiti, ...
Welches am besten passt hängt von deinen Anforderungen und Vorstellungen ab.

Wie man an den Zest Snippets sieht sind einfache Graphen damit sehr leicht umzusetzen (die Visualisierung kann man sehr frei gestallten):
http://dev.eclipse.org/viewcvs/view...GraphSnippet1.java?root=Tools_Project&view=co

```
public static void main(String[] args) {
		Display d = new Display();
		Shell shell = new Shell(d);
		shell.setText("GraphSnippet1");
		shell.setLayout(new FillLayout());
		shell.setSize(400, 400);

		Graph g = new Graph(shell, SWT.NONE);

		GraphNode n = new GraphNode(g, SWT.NONE, "Paper");
		GraphNode n2 = new GraphNode(g, SWT.NONE, "Rock");
		GraphNode n3 = new GraphNode(g, SWT.NONE, "Scissors");
		new GraphConnection(g, SWT.NONE, n, n2);
		new GraphConnection(g, SWT.NONE, n2, n3);
		new GraphConnection(g, SWT.NONE, n3, n);
		g.setLayoutAlgorithm(new SpringLayoutAlgorithm(LayoutStyles.NO_LAYOUT_NODE_RESIZING), true);

		shell.open();
		while (!shell.isDisposed()) {
			while (!d.readAndDispatch()) {
				d.sleep();
			}
		}
	}
```
Vorraussetzung für alle diese Frameworks ist aber das es sich um etwas Graphähnliches handelt.


----------



## Marco13 (8. Feb 2011)

Wildcard hat gesagt.:


> Geht es vielleicht um eine Graph ähnliche Visualisierung?
> Da gibt es dann schon ziemlich viel fertiges.
> Mein Liebling für einfache Dinge ist Zest.



Kann es sein, dass dort auf "einfache Dinge" eine subtile Betonung lag? Hab' mir Zest mal angesehen... abgesehen davon, dass es kaum Doku dazu gibt (weder reine API-Docs, noch eine "high-level"-Beschreibung der verwendeten Ansätze) scheint es mir, soweit ich das bisher gesehen habe, nicht so viele "Eingreifmöglichkeiten" zu bieten....?


----------



## Wildcard (8. Feb 2011)

Marco13 hat gesagt.:


> Kann es sein, dass dort auf "einfache Dinge" eine subtile Betonung lag? Hab' mir Zest mal angesehen... abgesehen davon, dass es kaum Doku dazu gibt (weder reine API-Docs, noch eine "high-level"-Beschreibung der verwendeten Ansätze) scheint es mir, soweit ich das bisher gesehen habe, nicht so viele "Eingreifmöglichkeiten" zu bieten....?



Zest ist für einfache interaktive Graphen. Für einen Full Blown Graphical Editor mit Bells and Whistles ist es definitiv das falsche Tool. 
Der komfortabelste Weg ist es mit den aus JFace bekannten Content- und LabelProvidern zu arbeiten.
Falls dir das nichts sagt, der Content Provider übersetzt das Domain Modell (beliebiges Modell) für den Viewer, der Label Provider gibt pro Domain Modell Objekt ein Label, Icon, Farbe,... zurück.
Man muss sich also überhaupt nicht mit Nodes und Edges herumschlagen, und kann mit (je nach Anforderung) 30 Zeilen Code ein komplex Modell als Graph rendern.
Das ist erstmal ziemlich cool, aber auch beschränkt.
Zest kann (ebenfalls gängiges Konzept aus JFace) in zwei Modi betrieben werden.
1. oben erwähnte Provider
2. Wie in den Snippets gezeigt in dem man GraphNodes und Edges händisch anlegt.

Customizing funktioniert in beiden Fällen, allerdings auf etwas anderem Wege. Ich erkläre es kurz an Alternative 2.
Du hast die folgenden "Eingreifmöglichkeiten" zur Verfügung (die Liste ist vermutlich nicht vollständig):
-Listener auf dem Modell um Aktionen auszuführen
-Double Click und Kontext Menü Aktions
-eigene Layout Algorithmen
-Eigene Animationen

Per Default kannst du erstmal nur Tooltip, Label, Icon, Border Color, Foreground Color, Fokus Appearance und Fisheye Modus auf den Knoten konfigurieren.
Wenn du mehr brauchst kannst du in Alternative 2. zum Beispiel GraphNode erweitern und dort createModelFigure überschreiben. Die Methode liefert eine IFigure zurück. IFigure ist das Basisinterface für Draw2D. Draw2D ist von den Möglichkeiten her etwa vergleichbar mit Swing Graphics2D bzgw dem Shape Interface, allerdings mehr auf Graphen zugeschnitten.
Damit kannst du also praktisch beliebig Zeichnen und ziemlich viel Visualisieren.

Man kann mit Zest zwar auch den Graph editieren, allerdings hast du dort kein mächtiges Editor Framework wie GEF zur Hand um das heavy lifting von Canoncial Updates, synchronisierung, undo/redo, Tool Support und was es alles gibt zu übernehmen.
Daher die Aussage reine Visualisierungen oder einfache Editoren funktionieren mit Zest. Aufwändige Editoren erfordern aber mächtigere und komplexere Frameworks, das ist bei Zest out-of-scope.


----------



## Marco13 (9. Feb 2011)

Ja naja, "Full Blown Graphical Editor mit Bells and Whistles" klingt jetzt als hätte ich unmögliches erwartet  Es ist aber etwas ... "pragmatischer" als ich vermutet hatte. 

Von JFace (und dass das Provider-Konzept dort ein fundamentaler Baustein ist) hatte ich noch nicht viel gehört, aber die Idee an sich natürlich schon, von daher kam dieser Abschnitt im Tutorial nicht so überraschend.

Der Fokus ist offenbar stark auf dem, was du beschrieben hast: Schnell ein Modell als Graphen darstellen zu können - aber statt runder Vertices nun eckige zu zeichnen ist erstmal nicht vorgesehen (zumindest nicht ohne einigen Implementierungsaufwand). Aber auch darüber hinaus ist eben einiges hart verdrahtet: Der Übergang zwischen zwei Layouts dauert 500ms, und das steht irgendwo als public static final definiert... 

In diesem Zusammenhang: Solche Sachen wie die GEF "Animation"-Klasse, die magisch Veränderungen mittrackt fand ich ... schon fast unheimlich  und vom Ansatz her schon fast "frech"-tricky. Für viele Anwendungen ist sowas sicher sehr praktisch, aber es schien als würde man schnell an Grenzen stoßen. Vielleicht kann man das als eine Instanz des üblichen Tradeoffs zwischen einfacher Verwendung und hoher Konfigurierbarkeit ansehen - oder einfach als eine andere Zielsetzung als ich zuerst vermutet hatte.


----------



## Wildcard (9. Feb 2011)

> Der Fokus ist offenbar stark auf dem, was du beschrieben hast: Schnell ein Modell als Graphen darstellen zu können - aber statt runder Vertices nun eckige zu zeichnen ist erstmal nicht vorgesehen (zumindest nicht ohne einigen Implementierungsaufwand).


Dann habe ich mich falsch ausgedrückt (lag vielleicht am Vergleich zu Graphics2D), das ist kein Problem. Draw2D ist wie gesagt sehr Graph Orientiert.
Um in obigem Snippet einen Knoten als Kreis darzustellen genügt zum Beispiel diese Änderung:

```
Ellipse ellipse = new Ellipse();
		ellipse.setSize(20, 20);
		GraphNode n = new CGraphNode(g.getGraphModel(), SWT.NONE, ellipse);
```
Draw2D Figures können ähnlich wie Swing Components behandelt werden, man kann ihnen Layout Manager setzen, Kinder hinzufügen usw.
Um da jetzt noch ein Label reinzubekommen müsste man der Ellipse einen Layout Manager setzen und ein Label adden.
Wenn man die komfortablere Variante mit dem Label und ContentProvider verwendet kann man IFigureProvider in seinem LabelProvider implementieren und dann pro Domain Objekt einfach eine IFigure instanzieren.
Um Mouseevents, Bounds checken, andocken von Kanten usw. muss man sich nicht kümmern.



> Aber auch darüber hinaus ist eben einiges hart verdrahtet: Der Übergang zwischen zwei Layouts dauert 500ms, und das steht irgendwo als public static final definiert...


Da hast du absolut recht, die hart verdrahtete Animationsdauer ist tatsächlich ein grober Design Schnitzer. Dafür gibt es aber einen Bug und AFAIK wird das im nächsten Release auch behoben sein.


----------



## Wildcard (9. Feb 2011)

Hier noch ein (sehr einfaches) Beispiel für das Label:

```
Label label = new Label("Paper");
		ellipse.setLayoutManager(new BorderLayout());
		ellipse.setSize(label.getPreferredSize().expand(15, 15));
		ellipse.add(label,BorderLayout.CENTER);
```



> Vielleicht kann man das als eine Instanz des üblichen Tradeoffs zwischen einfacher Verwendung und hoher Konfigurierbarkeit ansehen - oder einfach als eine andere Zielsetzung als ich zuerst vermutet hatte.


Da liegst du absolut richtig. Du musst den Kontext sehen aus dem das Tool kommt. Eclipse hat wohl die mächtigsten Graph Frameworks schlechthin mit GEF, Draw2D, GMF, Graphiti. Alle sind sehr flexibel, mächtig, und können irre kompliziert werden 
Manchmal ist ein kleiner, hübscher Graph sehr wünschenswert, allerdings ist er kein integraler Bestandteil und daher will man nicht zuviel in die Entwicklung stecken.
Dafür ist Zest dann ideal. Man hat mit wenigen Zeilen Code was hübsches, das dank der Animationen usw. nach viel mehr Arbeit aussieht als es tatsächlich war.
Wird zB von PDE, m2Eclipse und Buckminster verwendet um Abhängigkeiten zwischen Komponenten zu visualisieren.
Dafür passt es perfekt, du kannst dank der JFace Viewer Architektur einfach Filtern, Pfade hervorheben, auf Doppelklick irgendeinen Editor aufmachen usw.
Was ich auch ganz toll fand war diese Idee:
Graphviz DOT as a DSL for Zest - Eclipsepedia
Damit kann man zB Diagramme in der  DOT Syntax in Java Doc schreiben und sie dann direkt in Eclipse aus dem Quellcode visualisieren


----------



## Marco13 (9. Feb 2011)

OK, das mit den anderen Vertextformen war dann vielleicht ein schlechtes Beispiel ... das liegt wohl auch daran, dass ich mit SWT bisher noch nicht so viel zu tun hatte - ansonsten würde man vielleicht leichter die Stellen erkennen, an denen man sich "einklinken" kann. Das...
_Wenn man die komfortablere Variante mit dem Label und ContentProvider verwendet kann man IFigureProvider in seinem LabelProvider implementieren und dann pro Domain Objekt einfach eine IFigure instanzieren._
... erinnerte mich zwar ein wenig an Geek and Poke - Hello World  aber ... ich habe eine Vorstellung, warum das so ist, und warum es Sinn macht. 
Die Graph Frameworks, die du erwähnt hattest, kenne ich zwar auch nicht wirklich, (Ansätze um mich mal mehr in Eclipse, RCP & Co reinzufräsen stehen irgendwo auf meiner Todo-Liste), aber sie unterscheiden sich wohl schon allein konzeptuell stark von Java, AJAX and Flash Graph Visualization and Layout , Jung oder anderen reinen Bibliotheken.
Das mit der DOT language hatte ich (als eine der wenigen Doku-Seiten zu Zest) zwar auch gesehen, konnte das aber noch nicht richtig einordnen - ich sehe, da ist noch einiges an :rtfm: notwendig...


----------



## Wildcard (9. Feb 2011)

> Die Graph Frameworks, die du erwähnt hattest, kenne ich zwar auch nicht wirklich, (Ansätze um mich mal mehr in Eclipse, RCP & Co reinzufräsen stehen irgendwo auf meiner Todo-Liste), aber sie unterscheiden sich wohl schon allein konzeptuell stark von Java, AJAX and Flash Graph Visualization and Layout , Jung oder anderen reinen Bibliotheken.


Ohne diese Frameworks schonmal benutzt zu haben würde ich das 'bejaen'.
Draw2D, darauf basieren alle anderen (Zest, GEF, Graphiti, GMF) ist wohl am ehesten mit anderen Graph Libraries zu vergleichen und dürfte sich auch konzeptionell nicht so sehr von anderen Unterscheiden.
GEF verwendet die Figures und Klassen aus Draw2D und bettet sie in ein Editierframework ein.
Darunter fallen Aufgaben wie Connection und Creation Werkzeuge, Palette, Model und View synchron halten, auf Nutzereingaben reagieren...
GMF kommt aus der Modelling Ecke und verfolgt den Ansatz einen lauffähigen initialen GEF Editor für EMF basierte Modelle zu generieren, weil GEF leider einiges an Boilerplate Code erfordert bis wirklich etwas sinnvolles zu sehen ist.
Graphiti geht einen etwas anderen Weg, ist aber auch für EMF basierte Modelle gedacht (allerdings geht es mit etwas mehr aufwand auch für beliebige Modelle).
Die Idee bei Graphiti ist es keinen Code zu generieren und stattdessen sinnvolle Defaults für Optik und Verhalten zu definieren die nach und nach durch customized Implementierungen ersetzt werden.
Das ist (zumindest was die Default Optik angeht) wie ich finde auch ganz gut gelungen.





Die generierten GMF Editoren sehen da initial etwas roher aus.
Sehr schön an Draw2D und GEF ist, das sie out-of-the-box viele nette Features wie Zoom, Grid, Ruler, Snap to Geometry, Snap to Grid, Snap to Ruler, Layout Algorithmen, Bendpoints, Connection Anchors, Line Routers usw. bieten.
GMF 2.1 New and Noteworthy - Eclipsepedia


----------



## Marco13 (9. Feb 2011)

Ja, du hast schon an anderen Stellen "wohlwollend" über Draw2D, GEF & Co, und insbesondere über EMF geredet, und das will ich mir schon mal ansehen. Aber das sind nur einige wenige der vielen, vielen Eclipse-verwandten Projekte, die mal einen näheren Blick wären. HartIV'ler müßte man sein :reflect:  Ansonsten beschäftige ich mich eher mit den "lower-leveligen" Sachen, aber ein bißchen mehr über solche (und speziell diese) Frameworks bescheid zu wissen, kann nicht schaden. Eigentlich hätte ich fast schon konkrete Anwendungsszenarien dafür, aber um sie wirklich "gut" nutzen zu können, muss man sich erst mal einarbeiten.


----------



## Wildcard (9. Feb 2011)

Marco13 hat gesagt.:


> Ja, du hast schon an anderen Stellen "wohlwollend" über Draw2D, GEF & Co, und insbesondere über EMF geredet, und das will ich mir schon mal ansehen. Aber das sind nur einige wenige der vielen, vielen Eclipse-verwandten Projekte, die mal einen näheren Blick wären. HartIV'ler müßte man sein :reflect:  Ansonsten beschäftige ich mich eher mit den "lower-leveligen" Sachen, aber ein bißchen mehr über solche (und speziell diese) Frameworks bescheid zu wissen, kann nicht schaden.


Das ganze Graph Zeug ist eine Sache, das ist natürlich sehr speziell, aber EMF ist wirklich das Killer Framework.
Ich beschäftige mich zur Zeit mit einer Anwendung bei der im Low-Level Bereich Skalierbarkeit, Performanz und minimaler Memory Footprint essentiell sind. Und dennoch, oder gerade deswegen zieht sich auch auf dieser Low-Level Schicht der Anwendung EMF durch alles.
Warum soll ich mich mit fehleranfälligen Optimierungen herumschlagen um noch etwas Performanz herauszukitzeln, oder ein Attribut einzusparen wenn EMF das für mich mit einer Einstellung im Genmodel erledigen kann?
EMF kann zB automatisch alle boolean Werte im Code in eine Bitmaske überführen und dabei auch Konsistenz sicherstellen wenn die Klasse vererbt wird und zusätzliche Member braucht. Die Interfaces bleiben davon unberührt und ich muss keine Zeile Code schreiben.
Warum soll ich mich darum kümmern das alles korrekt lazy initialisiert wird, wenn EMF das für mich übernehmen kann?
Warum sollte ich mich darum kümmern zu entscheiden ob und wie lange sich verschiedene Objekte die gleiche Listener Liste teilen können um Heap zu sparen wenn es ein Framework übernehmen kann?

Die Hemmschwelle gegenüber MDD ist bei vielen Entwicklern immer noch sehr groß, aber wer über seinen Schatten springt wird meistens belohnt. 
Ständig stolpert man über Aussagen wie diese:


> It's official — I ♥ EMF!
> 
> This is a surprise to me. I previously regarded modelling in general and EMF specifically as a sort of cult… obscure jargon, terrible documentation, unbearably aloof and patronising talk abstracts… but all that’s behind me now. I see the light: it’s all about the industrialisation of software, which requires both componentisation and automation. OSGi provides admirably for the first, and perhaps EMF can provide for the second.


Using EMF in OSGi // Neil Bartlett


----------



## Marco13 (9. Feb 2011)

Die möglichen Vorteile sind mir schon bewußt. Ich bin mir nur nicht sicher, wie groß die Überschneidungen der Bereiche sind, in denen das gut und sinnvoll eingesetzt werden kann, und mit denen ich mich (üblicherweise) beschäftige. Wenn man seine Zeit in erster Linie mit ""Wartung"" bestehender Software verbringt, passt das natürlich nicht. Und je nachdem, wie weit das, was man (in seiner Freizeit) programmiert, von etwas weg ist, was man "als 'ganz normales' Business-Modell mit UML hinpinseln könnte", könnte es auch mehr oder weniger geeignet sein. Aber um das wirklich einschätzen zu können, muss man erstmal ein bißchen lesen und ausprobieren. 
Vermutlich bin ich nicht der einzige, der dabei erstmal (noch nichtmal so sehr die "befremdliche Verkultung" aus dem Zitat, sondern eher) eine Art "Kontrollverlust" (über den (generierten) Code) fürchtet. Aber ich finde, dass gerade die Punkte, die du genannt hast (irgendwelche Flags und Listener-Verwaltung) so stumpf und repetitiv sein können, dass man sie oft nur zu gerne automatisieren würde...


----------



## Wildcard (10. Feb 2011)

> Wenn man seine Zeit in erster Linie mit ""Wartung"" bestehender Software verbringt, passt das natürlich nicht


Absolut. Wenn im Zuge der Wartung keine großen Umbaumaßnahmen geplant sind um die Wartung in Zukunft zu vereinfachen ist Modelling fehl am Platze.


> Vermutlich bin ich nicht der einzige, der dabei erstmal (noch nichtmal so sehr die "befremdliche Verkultung" aus dem Zitat, sondern eher) eine Art "Kontrollverlust" (über den (generierten) Code) fürchtet.


Ja, das kam mir auch schon häufiger im Zuge von Schulungen und der Gleichen unter.
Ich versuche dann immer klarzumachen das Codegenerierung nicht die Kreativität beschneidet, sondern unterstützt. Je weniger Zeit ich damit vergeuden muss Alltagsaufgaben wie getter, setter, listener, default werte, toString Methoden,... zu kodieren umso mehr rückt der kreative Teil der Arbeit in den Mittelpunkt und um so mehr Spaß macht die Sache auch.
Im übrigen sind gerade gut Implementierte Observer Schnittstellen absolut nicht trivial. Wenn man die richtigen Patterns kennt ist das kodieren sehr einfach, aber immer gleich. Kenn man die Patterns nicht, macht man schnell Fehler und diese Fehler werden durch Code Generierung eliminiert.
Wir arbeiten in einem verteilten internationalen Team und EMF hat uns wirklich extrem geholfen im 'internationen Teil des Teams'  produktiver zu werden.
Wir überlegen uns in Deutschland ein Model und gießen es in ein Ecore. Das Ecore bekommt der betreffende Entwickler um daraus den Model und den Unit Testcode zu generieren.
Der Entwickler muss dann nur noch die im Ecore definierten abstrakten Methoden (EOpperations und derived Features) mit Leben füllen, die javadoc anreichern und die generierten JUnit Test Stubs ausfüllen. Wenn die Tests dann durchlaufen kann man schon ziemlich sicher sein das alles so funktioniert wie man es in Deutschland geplant hatte.


----------



## Marco13 (10. Feb 2011)

Ja, im Zuge eines Refactorings mal zumindest Teilweise "Module" zu extrahieren, die dann potentiell durch sauber modellierte erstetzt werden könnten, wäre mal was, aber es geht nur um Pseudofeature-Rumgehacke (Zeitverschwendung, aber was macht man nicht alles für Geld). 
Für den Schritt zwischen Planung (und sei sie nur "virtuell" im Kopf) und dem ganzen "Boilerplate"-Code, den man dann hinschreibt ein Tool zu haben ist sicher nicht verkehrt. Solche Ansätze wie Lombok fand ich da schon cool, aber das hat nichts mit Modellierung zu tun. Ich werde wohl wirklich mal einen Zeitblock allokieren müssen, um mir das näher anzusehen. Die Zeit, die man dann ggf. später dadurch sparen kann, sollte das schnell amortisieren können.


----------



## schalentier (10. Feb 2011)

Mhm, auch wenns jetzt eigentlich nix mit dem Topic zu tun hat:

Wenn man feststellt, dass man fuer die Loesung eines gegebenen Problems zuviel Boilerplatecode in Java schreiben muss, ist es dann ein sinnvoller Weg, ein weiteres Framework zu nutzen/zu entwickeln/einzubinden um sich eben jenen Boilerplatecode zu ersparen? Waere es nicht irgendwie sinniger, gleich eine Sprache zu benutzen, in der man das Problem besser, kuerzer und einfacher loesen koennte?


----------



## Marco13 (10. Feb 2011)

Ja, man kann z.B. "Hello World" oder "99 bottles of beer" mit HQ9+ schreiben :joke: 
Sicher kann man sich nach anderen Sprachen umsehen. Erst kürzlich habe ich wieder gemerkt, wie dramatisch viel weniger "Boilerplate Code" man bei Java im Vergleich zu etwa C++ schreiben muss. Nur hat man oft nicht die Wahl, oder ist in der Auswahl eingeengt (welche "echten", gleichwertigen Alternativen zu Java gbt es? C# ist auch nicht werniger verbose). Die Java-Aliens wie Scala können vielleicht viel Code sparen, aber wenn es dann um High-Level Dinge (wie Graphenzeichnen, oder High-Level-Modellierung) geht schadet ein Framework da auch nicht.


----------



## Guybrush Threepwood (10. Feb 2011)

Es gibt schon irrsinig tolle Sachen, die man mithilfe eines Frameworks mit relativ wenig Code in Java hinbekommt. Ich habe mich die letzten Tage ein bisschen bezüglich 2D Game engines schlau gemacht. Absolut faszinierend finde ich viele Beispiele von PulpCore, z. B. die "Physics Engine" (Physics ), aber auch die Partikel-Effekte und vieles mehr. Ich bin nicht mit Flash vertraut, und weiß nicht, wie leicht es dort ist. Vermutlich lassen sich komplexe Sachen auch dort nur mit einigem Aufwand hinbekommen. Es gibt an Java aber 2 Sachen, die meiner Meinung nach wirklich verbesserungswürdig sind:
1.) Animationen und schicke Oberflächeneffekte sind mit einem großen Aufwand verbunden. Man bekommt solche Sachen natürlich hin (siehe z. B. "Filthy rich Clients"), aber eine einfachere Handhabung wäre schon eine gute Sache.
2.) Im Vergleich zu Flash die Skalierbarkeit der Oberfläche und von Grafiken. In Flash werden ja generell die Vektorgrafiken direkt in Code übersetzt und dann gezeichnet. In Java ist das noch nicht gleichermaßen möglich, dabei wäre mit Java2D praktisch alles gleichermaßen möglich. Ein paar zarte Pflänzchen in diese Richtung gibt es ja, z. B. svg2java - Project Hosting on Google Code oder http://idisk.mac.com/han.solo-Public/Presentations/ForgottenPowerOfSwing/ForgottenPowerOfSwing.pdf und SteelSeries Demo ).

Vielleicht werden die in Java SE portierten JavaFX-Anteile einiges in diese Richtung bringen?

Ciao!


----------



## Marco13 (10. Feb 2011)

Ich könnte mir vorstellen, dass die Vielfalt auch Nachteile hat. Einerseits ist sie natürlich toll und wichtig, aber ... welches "Fundament" muss eine Bibliothek oder ein Framework haben, damit man seine Software darauf aufbaut, die auch in 10 Jahren noch laufen soll? Bei Eclipse-Projekten kann man sich ziemlich sicher sein, dass es nicht morgen schon heißt: "Die Entwicklung von Draw2D wurde eingestellt". PulpCore kannte ich nicht, es sieht wirklich gut aus (so gut, dass es mich wundert, dass ich vorher noch nichts davon gehört hatte), aber das heißt nicht, dass so etwas dort ausgeschlossen ist. Es muss erstmal eine "kritische Masse" erreicht werden, so dass ein Projekt so viele Anhänger findet, dass es sich selbst trägt. Bei (in bezug auf die Lizenzen) offeneren Bibliotheken ist das wahrscheinlicher, aber auch noch kein Garant.


----------



## Wildcard (10. Feb 2011)

schalentier hat gesagt.:


> Wenn man feststellt, dass man fuer die Loesung eines gegebenen Problems zuviel Boilerplatecode in Java schreiben muss, ist es dann ein sinnvoller Weg, ein weiteres Framework zu nutzen/zu entwickeln/einzubinden um sich eben jenen Boilerplatecode zu ersparen? Waere es nicht irgendwie sinniger, gleich eine Sprache zu benutzen, in der man das Problem besser, kuerzer und einfacher loesen koennte?


Modelling geht da schon einen ganzen Schritt weiter als JAXB artig getter und setter zu generieren, keine Sorge.
Ich kenne keine general Purpose Sprache die zum Beispiel Containment Beziehungen als First Class Citizen behandelt oder etwas vergleichbares wie die EMF Reflection API bieten würde.
Übrigens am wenigsten Boilerplate schreibt man mit spezialisierten DSLs und die besten Werkzeuge um DSLs zu definieren kommen wieder aus der Modelling/EMF Ecke.


----------



## hutzlibu (24. Mrz 2011)

Ist zwar nun schon ein bisschen her, aber trotzdem nochmal danke für all die Antworten.
Hatte mich auch mal etwas näher mit den erwähnten Frameworks auseinandergetzt ... und einige hatten auch einen recht guten Eindruck gemacht, aber richtig zufrieden war ich mit keinem.

Was mir allerdings auf Anhieb gefallen hatte ist dass da: haXe
Scheint zwar noch nicht alles perfekt ausgereift zu sein, aber es bietet doch sehr viel versprechende Ansätze, vor allem, wenn man wie ich aus der Actionscript-Welt kommt ...
Von daher werde ich wohl doch nicht in das Java-Universum eintauchen, alles in allem ist mir die Sprache doch zu technisch :bae:


----------

