Erfahrungen mit Eclipse 4: aus der Praxis für die Praxis

Von Marc Teufel

Am Anfang war ein Migrationprojekt. Im ersten Kapitel des shortcuts wird daher zunächst berichtet, wie an die Migration herangegangen wurde und welche Hürden zu nehmen waren, um die Transformation der umfangreichen Oracle-Forms-Anwendung auf die Eclipse Application Platform erfolgreich auf den Weg zu bringen. Das zweite Kapitel geht vor allem auf die Dynamik der neuen Eclipse-Plattform ein und zeigt, wie gerade diese Dynamik das Entwicklerteam unterstützt hat, den vorher gewählten Architekturentwurf umzusetzen. Im letzten Kapitel geht es schließlich um Dependency Injection (DI). Hiermit zieht ein modernes, zeitgemäß Entwurfsmuster in das Eclipse-RCP-Framework ein, daher wird zunächst erklärt, warum man sich bei Eclipse für diesen Schritt entschieden hat. Im Anschluss werden verschiedene Möglichkeiten gezeigt, wie man DI verwendet und kontrolliert. Aus der Praxis für die Praxis.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 18. Juli 2014
• ISBN: 9783868025118

Buchvorschau

Marc Teufel

Erfahrungen mit Eclipse 4

aus der Praxis für die Praxis

ISBN: 978-3-86802-511-8

© 2014 entwickler.press

Ein Imprint der Software & Support Media GmbH

1 Herangehensweise und Hürden

Die Eclipse 4 Application Platform ist mittlerweile schon einige Zeit am Start, und in der Vergangenheit durfte ich mich intensiv und viel mit der neuen Rich Client Platform beschäftigen. Zur Vorbereitung auf mein Eclipse-4-Buch, das bereits im November 2012 bei entwickler.press erschien [1], hatte ich bereits einige Nächte vor dem Monitor verbracht und war in die Tiefen des Eclipse-4-Quellcodes hinabgestiegen, um zu verstehen, was intern alles vor sich geht. Dem Ein- und Umsteiger in bzw. nach Eclipse 4 hilft das Buch daher bestimmt. Allerdings kann es natürlich nicht auf alle Eventualitäten eingehen. Das erfuhr ich am eigenen Leib, als ich selbst anfing, im Rahmen eines Migrationsprojekts eine sehr große firmeninterne Logistikanwendung von Oracle Forms auf die Eclipse 4 Application Platform zu migrieren. In diesem Kapitel möchte ich von meinen Erfahrungen berichten, etwas auf die von mir gewählte Architektur eingehen, vor allem aber einige Tipps und Tricks weitergeben, die ich im Rahmen meiner Arbeit gesammelt habe.

Natives Eclipse 4 ohne Compatibility Layer

Da es sich bei meinem Vorhaben, auch wenn es um eine Migration ging, um ein neues Projekt handelte, mit dem ich quasi auf der grünen Wiese starten konnte, war von Anfang an klar, dass ich nativ auf der Eclipse-4-Plattform aufsetzen werde. Auch wenn noch nicht wirklich alle Bestandteile, die in der alten RCP-Welt verfügbar waren, in der nativen Eclipse-4-Welt vorhanden sind, war der Einsatz des Compatibility Layers für mich dennoch keine Option. Wozu auch? Diese zusätzliche Schicht war nicht wirklich erforderlich, weil kein alter RCP-Code wiederverwendet werden musste. Außerdem hätte der Einsatz des Kompatibilitätsmodus nur für zusätzliche Komplexität im Projekt gesorgt, und das Ganze nur, damit man auf bestimmte Funktionalität wie etwa das Package org.eclipse.ui.* (hier immer wieder gerne benutzt: der ListSelectionDialog) zurückgreifen kann? Nein, danke.

Ich habe mich für den einfacheren Weg entschieden und an der einen Stelle, an der ein solcher ListSelectionDialog Sinn ergeben hätte, einfach eine eigene Implementierung (auf Basis der Quellen von ListSelectionDialog) erstellt. Offensichtlich hatten andere Entwickler ähnliche Probleme und Anforderungen wie ich, denn im Eclipse-4-Bugtracker findet sich bereits ein entsprechender Eintrag [2], der genau auf diese Problematik hinweist. Man kann also davon ausgehen, dass die fehlenden Bestandteile sich bald auch in der nativen Eclipse-4-Umgebung finden werden.

Ein paar Worte zu Dialogen

Wo wir gerade schon von Dialogen sprechen: Diese sind im aktuellen Release der Eclipse 4 Application Platform ohnehin noch nicht ganz ausgegoren. Man kann sie zwar verwenden, aber eben nur so, wie wir es aus Zeiten der Rich Client Platform 3.x gewohnt sind. Das ist zwar kein Rückschritt, aber in Verbindung mit der nativen Eclipse-4-Plattform ergibt sich derzeit ein leichter Nachteil: Dialoge und Wizards sind in keiner Weise Bestandteil des Application Models, sondern stehen für sich alleine. Das hat den Effekt, dass Wizards und Dialoge nicht über den EModelService gesucht, gefunden, verändert und gestartet werden können, so wie es für alle sonstigen Bestandteile einer Eclipse-4-Anwendung möglich ist. Ferner können selbst implementierte Dialoge und Wizards nicht so schön am Dependency-Injection-Mechanismus teilnehmen wie die Elemente, die Teil des Application Models sind. In meinem konkreten Fall bedeutete dies für die verwendeten Dialoge, dass diese dann eben „von Hand" instanziiert werden mussten. Das bedeutete dann auch,