Interview mit Gunnar Wagenknecht

Eclipse Juno Highlight #6: Innovationen in EclipseRT

Wir unterhielten uns mit Eclipse-Gyrex-Projektleiter Gunnar Wagenknecht über die Neuerungen, die das Eclipse-Juno-Release für die Runtime-Projekte mit sich bringt. Denn nicht nur der Tooling-Bereich glänzt in Juno mit interessanten Innovationen…

JAXenter: Eclipse Juno ist erschienen. Als wichtige Neuerungen werden meist eher traditionelle Development-Themen benannt: die neue Plattform 4.2, Orion, intelligentere Code Completion, Git, Xtext. Man bekommt den Eindruck, dass dieses Mal der Runtime-Bereich neben solchen Innovationen etwas im Schatten steht.

Gunnar Wagenknecht: In der Tat gab es mit Juno jede Menge Innovation im Tooling Bereich, aber der Runtime-Bereich braucht sich nicht zu verstecken. Equinox implementiert die neue OSGi-R5-Spezifikation, und Jetty implementiert das von Google ins Leben gerufene SPYD-Protokoll. Virgo gibt es in einer neuen Nano-Distribution, die Equinox-Konsole ist per SSH erreichbar, Riena unterstützt Eclipse 4 und RAP bringt ein neues, leichtgewichtigeres OSGi Application-Modell mit, was wir in Gyrex auch schon eingebaut haben.

JAXenter: Welche Auswirkungen hat die neue Plattform 4.2 auf Eclipse-Runtime-Projekte?

Gunnar Wagenknecht: Die Auswirkungen sind ganz unterschiedlich. Im Kern wird auch die 4.2-Plattform von Equinox 3.8 angetrieben. EclipseRT-Projekte, die ausschließlich auf Equinox aufsetzen, spüren keine Auswirkungen.

Projekte wie RAP und Riena sind aber schon stärker betroffen. Zwar bringt 4.2 auch einen Kompatibilitätslayer mit, der musste aber zumindest während des Entwicklungszyklus auf Herz und Nieren geprüft werden. Letztendlich steht diesen RT-Projekten aber nun auch das neue Programmiermodell offen. Gegebenenfalls sind dadurch auch Code-Anpassungen notwendig geworden.

JAXenter: Bleiben wir noch bei Eclipse Runtime: Wie du gesagt hast, ist ja die Unterstützung für die OSGi-R5-Spezifikation hinzu gekommen. Welche Innovationen bringt das mit sich?

Gunnar Wagenknecht: Die Innovationen sind im Core-Bereich eher kleiner Natur. Sie stellen aber sicher, dass Unterschiede zwischen den Frameworks und Framework-Tools abgebaut werden können und Funktionen, die vorher Framework-spezifisch waren, nun standardisiert angeboten werden können.
Beispielsweise ist das Handling von Versions-Bereichen standardisiert wurden.

Im Enterprise-Bereich ist die Liste deutlich Länger. Eine Repository-Spezifikation wird künftig dafür sorgen, dass alle Frameworks über ein einheitliches Repository-Format bedient werden können. Der interne Resolver zum Auflösen von Abhängigkeit kann nun auch extern genutzt werden, sodass sich Installationsroutinen zukünftige vorher in einem laufenden Framework simulieren lassen. Weiterhin wird mit der ServiceLoader-Spezifikation die Interoperabilität mit existiernden Bibliotheken verbessert.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.