Eclipse und der weite Weg von Windows nach Vista

Alle Wege führen nach Vista

Lars Wunderlich

Seit 30. Januar können Kunden offiziell Microsofts Windows VistaTM im Laden käuflich erwerben. Die Suche nach kompatibler und voll lauffähiger Software hingegen geht wie bei jeder neuen Windows-Version eher schleppend vonstatten. Eclipse 3.3 ist die erste Version, bei der volle Vista-Kompatibilität auf den Fahnen steht. Wir schauen uns im folgenden Artikel an, ob Eclipse schon in Vista angekommen ist und ob sich der Umstieg lohnt.

Schon am 23. August 2005, also mehr als ein Jahr vor der öffentlichen Präsentation von „Longhorn“ und rund ein Monat nach der ersten Betaversion, stellte Ed Burnett in seinem EclipseZone-Artikel [1] einen Screenshot von Eclipse 3.1 unter Vista vor [2]. Damit war die grundsätzliche Basislauffähigkeit zwar bewiesen, zwischen „lauffähig“ und „vollständig kompatibel“ sollten aber noch viele kleine Schritte folgen.

Vista-Kompatibilität heißt dabei, Eclipse mit Sun Java 2 Standard Edition 5.0 Update 11, IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR4 und BEA JRockit 5.0 zum Laufen zu bekommen. Während dies noch eine zunächst eigentlich relativ einfache Aufgabe zu sein scheint, setzt Microsoft die Latte mit neuer Aero-Oberfläche [3] und 32- sowie 64-Bit-Varianten seines Betriebssystems trotzdem hoch an. Besonders schwer fällt der Eclipse-Gemeinde hier, die Kompatibilität ihres selbst definierten SWT-Oberflächen-APIs zum Betriebssystem wieder herzustellen, denn Windows ist ja nicht gleich Windows. Bei derartiger Portierung zeigt sich immer wieder auch in gewisser Weise die Schwäche des Eclipse-Ansatzes, statt des Java-eigenen Swings und dessen sicherlich auch nicht gerade einfacher Portierung für die Bedürfnisse von Vista sich durch das Standard Widget Toolkit auch noch eine eigene UI-Migration antun zu müssen.

Installationen in der Sandbox

Wer den Verlockungen des Windows-Erwerbs nicht widerstehen kann oder eine der Live CD-Varianten zum Laufen bekommen hat, kann sehr einfach bei der Installation von Windows auf Nummer sicher gehen. Anstatt das gute alte XP zum Teufel zu jagen, empfiehlt sich für vorsichtige Gemüter die Nutzung eines kostenlosen virtuellen PCs [4], der ab 1GHz bestenfalls mit Parallelprozessor und 1024 MB RAM gestartet werden kann.

Wer Suns Java Virtual Machine dann auch auf Vista installieren möchte, greife bestenfalls zu den aktuellsten JRE-Versionen 5.0 oder 6.0. Auch mit der 6.0er Java-Version lässt sich Eclipse 3.3, das ab Milestone 6 offiziell als Vista-kompatibel proklamiert wird, problemlos starten, und die eine oder andere Testtour lässt sich drehen. Da Vista als streng sicherheitsgetriebenes OS ja einen starken Hang zu unsicherem Entscheidungsverhalten aufweist und bei faktisch jeder das System beeinflussenden Aktion den oft hilflosen Benutzer mit Nachfragen traktiert, tauchen bei Installation der Java SE aber auch beim Starten von Debug-Prozessen in Eclipse hin und wider Warnmeldungen und Rückfragen auf.

Abb. 1: Warnhinweis-Installation JDK

Abb. 2: Vergleich Eclipse in Vista und XP

Nach der Installation bzw. dem Entpacken von Eclipse präsentiert sich die Entwicklungsumgebung in gewohntem Design, allerdings mit einem starken Hang zur Ähnlichkeit mit der ursprünglichen Linux-Variante.

Abb. 3: Windows-Firewall-Warnung beim Debuggen
.NET/Java-Integration?

Avalon ist der Gralsgeschichte nach die Apfelinsel und in der Mythologie der Ort, an den sich König Artus nach seiner Verwundung zurückzieht. Für Apache und Microsoft hat der gleiche Codename weniger mythischen Charakter. Microsoft verbindet damit die Windows Presentation Foundation (WPF), eine Präsentations-Programmierschnittstelle für Microsoft Windows, die im .NET-Framework integriert auch in Vista vorhanden ist. Sie steuert aufsetzend auf DirectX und mit Hardwarebeschleunigung 2D-/3D-Grafiken, Videos, Audioformate und Bilder. WPF steuert sich dabei automatisch und passt das Compositum aus bunten Vista-Effekten an die Möglichkeiten der Hardware an.

Unwichtig war die WPF für die Anpassung von Eclipse an Vista tatsächlich nicht, denn man hatte sich in der Roadmap zu Eclipse 3.3 doch auf die Fahnen geschrieben, SWT in Richtung WinFX und WPF zu portieren und dabei die 32- sowie die 64-Bit-Versionen gleichzeitig zu bedienen. Die Ernüchterung folgte allerdings alsbald u.a. im Eclipse Feature 154117. Die Auslieferung einer WPF-fähigen Version bedeute zu Recht eine Integration von Java und .NET. Da .NET 3.0 nicht verpflichtend als Installationsvoraussetzung für Windows daherkommen durfte, um Windows-Altanhänger nicht zu vergraulen, musste eine zweite Version von Eclipse 3.3 her, mit der Endung „wpf“, derzeit zu finden als „Early Access“-Version. Die 64-Bit-Version hingegen ging derweil zunächst nicht einmal in Planung [6]. So bleibt das Bemühen um eine verstärkte Weiterentwicklung an diesen Themen in weiteren Releases zunächst Randbemerkung in der Roadmap. Die bereits getätigten SWT-Weiterentwicklungsversuche der Community in Richtung win64 werden dabei dankend als zusätzliche Ausgangsbasis angenommen (Bug 154118). Ende April 2007 bleibt das Thema offener Diskussionspunkt mit niedriger Priorität für ein Eclipse 3.3 Release.

Keine 8 Bytes für 64 Bit

Wie es scheint, bleiben 64-Bit-Systeme somit eine Lücke bei Eclipse – zumindest vorerst –, die in der Liste der kompatiblen System auch nicht vorkommt. Jene Entwickler, die sich mutig neuer Hardware und neuem Vista 64 gestellt haben, bekommen denn auch das JDK in der 64-Bit-Version zumindest in den Milestones nicht immer mit Eclipse zum Laufen [7]. Andere wiederum benennen fehlende JRE-Installationen als Stolperstein und merken an, der Launcher für Eclipse würde gegebenenfalls das JRE nicht immer finden.

Die Java-Entwicklung selbst sei zwar auch mit dem 64er JDK grundsätzlich möglich, Eclipse allerdings müsse man aber in einigen Fällen mit einer eigenen 32-Bit-Version erst eine Basis zum Starten verschaffen. Ein wenig holprig fühle sich aber der Milestone trotzdem an.

Termindruck?

Ein wenig entsteht der Eindruck, man arbeite bei Eclipse in den letzten Jahren doch unter erhöhtem Termindruck. Während Open-Source-Projekte bislang immer so einen Touch von freiem Müßiggang und undisziplinierter Software-Evolution besaßen, dürfte der Spaß bei Eclipse  bei der Koordinierung von verteilten Projekten in mancherlei Hinsicht auch an Grenzen stoßen.

Allein ein Europa Simultaneous Release geplant für den 6. Juni 2007 und die Konsolidierung der verschiedenen Projektaktivitäten und Ressourcen dürfte schon einige Beteiligte ins Schwitzen bringen. Selbst wenn es bei Open-Source-Projekten gerne mal das ein oder andere Jahr Verschiebung gibt, so haben doch mindestens die kommerziell und finanziell beteiligten Mitglieder der Eclipse-Gemeinde bei bestimmten Release-Zyklen auch eigene Interessen, oder wer von uns muss jetzt unbedingt nächste Woche die neue SWT-64-Bit-Version seiner Software abliefern?

Die nur etwa 120 der 26.700 verzeichneten Bugs in der Liste der Bugs und Features für Eclipse, die sich auf Vista beziehen, machen zunächst einen prozentual verzichtbaren Eindruck. Wem ein solcher Bug natürlich aber doch zur Last fällt, der hat zunächst einmal das Nachsehen. Die Win32-Portierung, die auch zahlreichen anderen Windows-Produkten eine zeitweise Überlebenschance in Vista einräumen dürfte, lässt auch Eclipse-Enthusiasten erst einmal durchatmen.

Die Fronten gegen die Bugflut bei Vista sind verteilt. Teilteams wie beispielsweise das Thema TPTP-(Test and Performance Tool Platform-)Team kämpfen mit Sicherheitseinschränkungen von System-Usern, andere befinden sich in Testzyklen zur Prüfung der Kompatibilität mit Vista (wie bei BIRT). Beim Gerangel um nicht funktionsfähige Tabellen, Scrollbalken oder Tree-Strukturen spielen schließlich auch ein paar RCP-Kandidaten mit, die Eclipse zur Plattform für ihre eigene Rich-Client-Software gemacht haben und nun in den Genuss von Windows Vista kommen wollen. Da gibt es die kleinen und großen Problemchen, wo der Javadoc-Kommentar die falsche Schriftart benutzt, der Cursor zu schnell oder mal zu langsam blinkt, die Netzwerklaufwerke manchmal verschwinden und Vistas IPv6-Standard nicht erfüllt wird.

Insgesamt, so waren meine eigenen Erfahrungen mit Eclipse 3.3 unter Windows Vista, ist Eclipse durchaus auf einer sauberen Vista-Installation zum Laufen zu bekommen. Insgesamt hielt sich Eclipse dabei sogar manchmal besser auf den Beinen als das Betriebssystem selbst, wobei die alten Milestones von 3.3 und 3.2 nicht gerade mit Stabilität unter Vista glänzten. Geschwindigkeitsseitig ließen sich spontan keine großen Unterschiede zum in die Jahre gekommenen Bruder XP ausmachen, was natürlich auch davon abhängt, wie weit man seine Hardware insgesamt mit Vista „belasten“ möchte.

Die eigentliche Herausforderung für die Entwickler von Eclipse bleibt eigentlich, die unterschiedlichen Strömungen der verschiedenen Betriebssysteme auf einem gemeinsamen Nenner und Niveau zu halten und gleichzeitig aber auch den verschiedenen Fähigkeiten Tribut zu zollen. Natürlich erwartet auch die Gruppe der RCP-Entwickler, dass sich auf Eclipse basierende Produkte möglichst nahtlos in die neuen Vista-Oberflächenelemente und –designs einfügen und dass die kleinen Minianwendungen hier und die neue Menüführung dort sich ebenfalls ganz homogen integrieren lassen. Ganz ohne Zugeständnisse oder Kompromisse dem ein oder anderen Betriebssystem gegenüber wird es dabei allerdings wohl nicht gehen.

Für jene, die sich auch mit einer älteren Eclipse-Version „begnügen“ mögen, haben Erfahrungen gezeigt, dass sich auch Eclipse 3.2.2 [8] unter Windows Vista gut schlägt, obwohl es nicht zu den angestrebten Zielplattformen des 3.2er Release-Zweigs gehörte. Eine sicherlich lohnenswerte Alternative, das alte Eclipse mal zu aktualisieren und mit dieser Version unter Windows zunächst fortzufahren.

Fazit

Mit dem Erscheinen der finalen Eclipse 3.3-Version dürfte es kaum triftige Gründe geben, nicht mit Eclipse 3.2.2 oder 3.3 unter Windows Vista zu starten. Wer bis dahin aber dramatische Oberflächenerweiterungen anstatt Basis-Kompatibilität erwartet, könnte enttäuscht sein. Blutspritzende Ego-Shooter, rauchende Rennmotoren und sozialisierende Big-Brother-Simulationen a la Sims werden wir wohl auch in den nächsten Wochen noch nicht auf 64-Bit-Vista mit SWT zum Laufen bringen können oder sehen (müssen). Vielleicht ist es aber auch eine rechtmäßige Freiheit von Open-Source-Tools, manche Dinge zu tun und andere besser erst noch zu verschieben.

Lars Wunderlich ist Autor zahlreicher Fachbücher und -artikel zu Themengebieten rund um Java. Er arbeitet als Software-Architekt in internationalen Großprojekten im Java Enterprise-Umfeld bei der TUI InfoTec GmbH in Hannover.
Geschrieben von
Lars Wunderlich
Kommentare

Schreibe einen Kommentar

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