Nachlese Eclipse Abend 2 | Print |
Written by Michael Jastram   
Thursday, 14 November 2013 19:16

Die rheinjug hatte es an diesem Abend gar nicht so leicht, da dieser Termin leider zeitgleich mit der Devoxx lag - da haben wir leider nicht aufgepasst. Trotzdem fanden sich ca 60 Besucher ein, die wissen wollten, was sich in der Eclipse-Welt so tut. Michael Jastram stellte zunächst die Rolle der Uni Düsseldorf im Eclipse-Umfeld vor. Seit ca. zwei Jahren ist die Universität akademisches Mitglied der Eclipse-Foundation, und stellt den Ursprung des Requirements Modeling Frameworks dar. Auch wenn Eclipse schon betagt ist, stellt es doch ein enormes Ökosystem dar, welches es ermöglicht, viele Probleme schnell und effizient zu lösen.

Alexander Nyßen begann die Vortragsreihe mit GEF, das inzwischen der Standard für grafische Editoren und Ansichten in Eclipse ist und letztes Jahr zehnjähriges Bestehen feiern durfte. Zest kam dann in 2007 als Visualisierungs-Toolkit dazu. Zehn Jahre ist eine lange Zeit, und um einige der über 400 Bugs zu lösen, müsste ein Bruch stattfinden, vor dem sich aus Legacy-Gründen die Community bisher gesträubt hat. Ein Mittelweg, der bei Zest gegangen wurde, ist eine Neuentwicklung (Zest 2), die aber nicht die alte Version ablöst, sondern unabhängig davon existiert. Das selbe ist der Fall mit GEF4, welches seit 2011 in Arbeit ist. Und um Redundanzen zu beseitigen, wurden die beiden Projekte unter dem Namen GEF4 vereint. Auch wichtig für viele Nutzer: GEF4 ist unabhängig von Eclipse. Insbesondere durch die Aktivitäten von Oracle im Bereich JavaFX, hat GEF4 die JavaFX-API unter dem Namen SwtFX "nachgebaut", um eine eventuelle zukünftige Migration zu erleichtern.

Thomas Schütz beschäftigt sich mit einem ganz anderen Thema, nämlich mit Realtime Object Oriented Modeling, einem Formalismus, der vom Eclipse etrice-Projekt realisiert wurde. Eine der Stärken von ROOM ist die Einfachheit des Metamodels - im Vergleich zu UML2, zum Beispiel, um eine Größenordnung kleiner. Mit ROOM können strukturelle Modelle und Verhaltensmodelle definiert werden, von denen performanter code generiert wird, der dann auf eingebetteten System betrieben wird. Der Kreis schließt sich mit modellbasiertem Debugging, von auf dem Controller ausgeführten Code. Die wichtigesten Elemente sind hierarchische Komponenten (Actors), die über Ports miteinander verbunden sind. Weiterhin gibt es Statemachines für das dynamische verhalten. Ganz wichtig: Alle grafischen Elemente haben eine textuelle Repräsentation. Im Gegensatz zu traditionellem objektorientierten Ansatz, kapselt ROOM auch die Parallelität. Jeder Aktor hat einen logischen Thread, der natürlich in der Implementierung nicht als eigener Thread realisiert werden muss. Wie das in der Praxis aussieht, zeigte Thomas mit Beispielen aus dem Automotive- und Finanzbereich

Marcel Bruch entwickelt seit Version 2.1 mit und für Eclipse. Zunächst zog er uns den Zahn, dass Eclipse 4 (E4) für die IDE etwas ändert, nämlich zunächst gar nichts. Denn auf E4 sitzt ein Kompatibilitäts-Layer, und darauf sitzt der ganze 3.x Legacy-Code. Dann stellte Marcel einige provokante Fragen: Was stört Euch an Eclipse? Ist es noch zeitgemäß? DAss es auch anders geht, zeigte Marcel mit einem kurzen Video von Bling (?), die eine openGL-basierte Implementierung gegen die SWT-API implementiert hatten. Die wabbelnden Fenster brachten haben die Besucher definitiv beeindruckt. Eine ähnliche Initiative ist mit JavaFX in Arbeit. Aber solche Ansätze ändern die GUI ja nicht grundsätzlich - ein komplett anderer IDE-Ansatz wurde bspw. mit Code-Bubbles realisiert. Auch zum Thema Debugging zeigt Marcell ganz neue Ansätze, die überhaupt nichts mit den heute bekannten Konzepten zu tun haben. Wie ist es denn mit Eclipse im Browser? Richtig cool fand das keiner, wobei schon der eine oder andere das als Nützlich bezeichnen würde. Dazu hat das Orion-Projekt beachtliches geleistet.

Aber wo ist die Zukunft von Eclipse? Die gute Nachricht: Das Problem ist erkannt, und es wird nach Lösungen gesucht. Durch kurzes Handzeichen stellte Marcel fest, dass doch einige im Publikum €30 für Eclipse zahlen würde, aber wenige Arbeitgeber würden das tun. Zuletzt stellte Marcel noch ein Konzept vor, bei dem nicht Geld, sondern implizite Mitarbeit gespendet wird, für einen erheblichen Gegenwert: Codetrails und Snipmatch sind Ansätze zum Crowdsourcing von Programmierwissen, das nicht nur auf Java beschränkt ist. Probiert es mal aus!

Wie üblich folgte hinterher bei einem Bier - mit oder ohne Alkohol - ein reger Gedankenaustausch.