Wie der geneigte Leser an den Posts in meinem Blog sehen kann, habe ich mich in der letzten Zeit mit verschiedenen IDEs im Zusammenhang mit verschiedenen Sprachen und Technologien beschäftigt. Auch wenn der Prozess der Sichtung noch nicht abgeschlossen ist, wage ich dennoch einmal den Vergleich zwischen den drei Major IDEs wenn es um die Entwicklung mit Java und anderen Sprachen geht. Ich werde nicht nach IDE sortieren sondern nach verwendeten Sprachen und Frameworks. Zur Verwendung kommen die aktuelle Eclipse 3.4 (mit Vorausschau auf 3.5), Netbeans 6.7 Beta und IntelliJ Idea 8.1.

PHP

Die PHP Unterstützung ist nur in Eclipse und in Netbeans gegeben. Das freie PDT in Eclipse ist gleichzeitig die Grundlage für das kommerzielle Zend Studio for Eclipse, die führende IDE im PHP Bereich. Von den Kosten kann man fairerweise nur PDT und das Netbeans-Plugin vergleichen. Beide haben einen großen Coding Comfort und die Debugger Unterstützung ist ausgereift. Beide bringen auch Standardfeatures ihrer jeweiligen Mutter IDE mit, also Code Folding, Zeilennummerierung, ausgefeilte Suchen & Ersetzen Funktionen, Filenavigator und eine Outlineansicht sowie Anzeigen über Probleme, Todos etc.

Das Zend Studio erweitert PDT in vielerlei Hinsicht, etwa um ausgefeiltes Codeformatting, Unittest-Unterstützung, Server-Debugging und vieles andere mehr. Das Zend Studio (und damit die Eclipse-Plattform) ist klarer Gewinner des Vergleichs es kostet aber auch an die 400 €. Bleibt man bei den kostenfreien Lösungen gewinnt meines Erachtens die Netbeans-Lösung vor Eclipse. Zum einen ist das Editieren von Code in vielerlei Hinsicht komfortabler, die IDE fühlt sich schneller an und vor allem sind mit Unittest-Unterstützung und Code-Coverage-Analyse bereits Pro-Features aus dem Zend Studio frei verfügbar.

Fazit: Auch für größere Projekte reicht die Netbeans-Lösung aus, in einem aktuellen Projekt spicht einzig das Code-Formatting noch unbedingt für Zend, alles andere könnte man vermutlich auch mit Netbeans erledigen.

Flex

Für Flex fällt Netbeans komplett aus, da es keinerlei Support bietet. Für Eclipse gibt es den großen Flex Builder von Adobe, der kostenpflichtig ist, es sei denn man ist Student oder grade durch die Wirtschaftskrise arbeitslos geworden. IntelliJ ist ja eine kommerzielle IDE, aber der Flex Support kostet keinen Aufpreis.

Der Flex Builder ist so ziemlich der Standard wenn es um Flex Entwicklung geht. Er hat einen einmaligen visuellen Editor, der Roundtip-Engineering zwischen visueller und coding Ansicht bietet. Flex Builder bietet in Sachen Run-Configuration, Debugging und Profiling so ziemlich alles was man benötigt. Der Editor ist jedoch nur mäßig, so gibt es kaum Möglichkeiten, die Sourcen zu verändern, noch nicht mal ein “Format Source” ist dabei. Für einige Sachen gibt es Plugins aber vieles bleibt außen vor. Der Flex Builder ist entweder Standalone mit Eclipse zu beziehen oder als Eclipse Plugin.

Ein zweites Eclipse Plugin sind die Flash Development Tools (FDT) von Powerflasher, die in ihrer neuesten und teuersten Version Unterstützung für Flex bieten. Der Coding Comfort soll hier sehr gut sein, aber für den fast doppelten Preis des Flex Builders ist das definitiv zu viel.

Eine Alternative bietet hier IntelliJ gerade wenn man noch in anderen Sprachen programmiert erhält man einen ausgezeichneten Flex Support. Die Editorfunktionen sind sehr umfangreich und man findet viele Features, die man normalerweise nur in einem Java-Editor finden würde. Idea 8 unterstützt auch das Debugging von Flex.

Fazit: Eclipse oder IntelliJ Idea ist hier die Entscheidung. Wer das eine oder das andere mag wird seine Flex IDE aus dem gleichen Hause nehmen. Gerade wenn beide Backends in Java gecodet werden spielt es keine Rolle. Ist das Backend zu einer Flexanwendung aber in PHP geschrieben so bietet sich die Kombination Zend Studio for Eclipse in Verbindung mit dem Flex Builder Plugin an.

Groovy & Grails

Für Groovy und Grails gibt es für alle drei IDEs Unterstützung aber in unterschiedlicher Qualität. Ein ziemlicher Ausfall ist das Plugin für Eclipse. Es kann sehr wenig und ist noch in einem frühen Stadium. IntelliJ war lange der Marktführer in Sachen Groovy-/Grails-Support, der Vorsprung schwindet aber mit jeder Version von Netbeans stärker. Die aktuelle Beta von Netbeans 6.7 reicht an die Fähigkeiten von Idea 8 heran. Hier entscheidet alleine, was es für Vorlieben gibt. Eclipse sollte aus der Entscheidung außen vorgelassen bleiben und wenn schon IntelliJ im Hause ist sollte man dabei bleiben. Startet man aber auf der grünen Wiese oder will einfach mal nur mit einer gescheiten Entwicklungsumgebung etwas Groovy und Grails programmieren, dürfte die Entscheidung eindeutig für die Netbeans 6.7 Beta ausfallen.

Java-Script / HTML

Java-Script wird von allen drei IDE hervorragend unterstützt. Für Eclipse gibt es mit Aptana sogar eine Distribution, die auf die JS Entwicklung abzielt. Idea 8 hat einen ebenfalls sehr guten Java-Script Support und zeigt dies eindrücklich mit dem Java-Script Debugger. Netbeans in der aktuellen Beta bringt auch einen exzellenten Java-Script Support mit und ist in Sachen Codeerkennung und Codevervollständigung vorne. Der HTML Support ist ebenfalls in allen drei IDEs gut bedacht und es macht für einen Entwickler durchaus Sinn eine der IDEs statt Dreamweaver :-/ oder anderer Tools wie Espresso zu benutzen. Die Entwicklungsgeschwindigkeit wird sich positiv bemerkbar machen. Man muss auch bei einer IDE nicht immer auf einen visuellen Modus verzichten.

Java

Last but not least will ich kurz auf Java eingehen, die Sprache, der alle drei IDEs ihre Existenz verdanken. Nicht nur weil sie in Java programmiert sind sondern auch weil Java die erste Sprache war, die sie unterstützten. Alle drei IDEs bieten einen hervorragenden Support für die Javaentwicklung und lassen kaum Wünsche übrig. Wer welche IDE für Java einsetzt, wird nach seinen Vorlieben (oder denen seines Projektleiters) entscheiden oder nach dem, was er gewohnt ist. Unterschiede gibt es trotz aller Gemeinsamkeiten dennoch. Ein großes Plus von Eclipse ist die Mannigfaltigkeit von Plugins, die einem die Javaentwicklung erleichtern oder diese Unterstützen. Neben dem freien Eclipse gibt es auch kostenpflichtige Distributionen, die spezielle Einsatzzwecke abdecken- Der Vorteil von Netbeans ist die Einfachheit der Inbetriebnahme. man installiert es lädt über den Plugin Manager ein paar Plugins nach und beginnt ein neues Projekt in kürzester Zeit. Wer einmal eine umfangreiche Eclipse-Installation aufgesetzt hat, kann davon nur träumen. IntelliJ Idea hat seine eingeschworene Nutzergemeinde und geht einen Sonderweg in Nutzerführung und IDE-Nutzung.

Fazit

Wer welche IDE nutzt sollte dies von seinen Vorlieben, den Vorgaben seiner Projekte und den Anforderungen abhängig machen. Geben sich die IDEs bei Java wenig, sieht es bei der Unterstützung für andere Sprachen schon wieder anders aus. Der Vorteil für den Entwickler ist, dass er für seine Technologie fast immer eine kostenfreie Option angeboten bekommt – nur selten ist ein Obulus für die Unterstützung einer Sprache notwendig. IntelliJ scheidet beim Thema Kostenfreiheit aus, da es kommerziell ist, genau wie der Flex Builder, Zend Studio oder MyEclipse. Netbeans, das lange das Stiefkind unter den IDEs war legt seit Version 6.5 ein atemberaubendes Tempo vor und hat zu den anderen IDEs längst aufgeschlossen. Es bleibt nur zu hoffen, dass Suns Übernahme durch Oracle nicht das Ende von Netbeans und die Entscheidung für JDeveloper bedeutet. Es wäre schade um eine gute IDE und auch die innovationstreibende Konkurrenz zu Eclipse wäre großteils verschwunden.

Wie auch immer die individuelle Entscheidung ausfällt, bleibt festzuhalten: Es ist gut, dass die Entwickler Freiheit in den eingesetzten Produktionsmitteln haben. Der zumeist kostenlose Zugang zu IDEs fördert auch den Zugang zur Programmierung. Und dass neben Java immer mehr Sprachen und Technologien einen zunehmend guten IDE Support erhalten ist wohl das größte Plus der aktuellen Entwicklung.

Erinnert sich noch jemand an SVG, jenes XML Format des W3C um skalierbare Vektorgrafiken zu beschreiben? Natürlich, noch ist es nicht ganz vergessen und einige Browser unterstützen dieses Format auch. Jedoch, man sieht es selten in der freien Wildbahn und die Einsätze sind nicht gerade zahlreich wenn man mal von etwas exotischeren Programmen wie Inkscape absieht.

Dabei ist die Idee hinter SVG nicht schlecht, sie ist sogar so gut, dass sie heute im RIA-Bereich eine maßgebliche Rolle spielt, wenn auch nicht in der Gestalt von SVG, sondern in moderneren, teilweise proprietären Formaten. Die Idee hinter SVG ist eine Grafik so zu beschreiben, dass die Beschreibung (mittels XML) für Maschinen wie für Menschen gleichermaßen lesbar ist. Hinzu kommt, dass man die Grafiken verändern kann, indem man zur Laufzeit Änderungen an der Beschreibung vornimmt.

Ich will jetzt gar nicht drauf eingehen warum SVG nicht der Flashnachfolger geworden ist, wie es sich die Open Standards Fraktion erhoffte. Vielmehr ist es interessant, dass die Grundidee der deklarativen Grafikbeschreibung im RIA Umfeld mittlerweile eine große Rolle spielt.

Für Flex gibt es mit dem Degrafaprojekt einen Ansatz, Grafiken deklarativ zu beschreiben. Mit der Creative Suite 4 und im Vorgriff auf das kommende Flex 4 (Codename Gumbo) setzt Adobe aber selbst ein deklaratives Grafikformat ein: FXG. FXG erlaubt den leichten Austausch von Grafiken in Textform. Flex 4 kann FXG-Elemente zur Laufzeit transformieren und bietet so einen neuen völlig neuen Ansatz zur Echtzeit-Grafikmanipulation und Animation. Die Ähnlichkeit von SVG und FXG reicht über XML als gemeinsame Basis hinaus – die Gründe warum sich Adobe jedoch für eine eigene Sprache entschieden hat, werden hier dargelegt.

Auch Microsofts Silverlight kann mittels XAML auch Grafiken beschreiben dazu kann ich jedoch mangels Erfahrung nicht mehr schreiben – auch hier ist wieder XML der gemeinsame Nenner.

Selbst der Nachzügler im RIA-Bereich Suns JavaFX verfügt über eine Methode um grafische Assets zu beschreiben und somit austauschbar zu machen. JavaFX nennt diese Dateien FXD (reine Beschreibung eines Vektorassets) oder auch FXZ (komplettes Archiv von grafischen Assets). Die JavaFX Production Suite erlaubt es mittels Plugins Photoshop- und Illustrator-Dateien in FXD/FXZ Dateien zu exportieren und direkt in JavaFX zu einzusetzen und zu verändern. Analog des Sprachdesigns von JavaFX sind die die FXD Dateien kein XML sondern eher etwas JSON ähnliches, Sun spricht von objektliteral und entspricht JavaFX Script selbst. Ob sich der Alleingang von Sun auf XML zu verzichten durchsetzt wird die Zukunft zeigen. Der Vorteil vom XML ist die Verbreitung von Tools und Know-how darüber, bei JavaFX muss von Neuem begonnen werden.

Es ist interessant zu sehen, wie sich die relativ neue Technologie der Rich Internet Applications dem Thema der deklarativen Grafikbeschreibung erneut annimmt. Auf der anderen Seite ist es bedauerlich, dass dem offenen Standard SVG keine rechte Chance gegeben wurde, seine Stärken in dem neuen Kontext auszuspielen.

Es weihnachtet schon sehr und es ist die Zeit des Tuns guter Dinge. Warum nicht auch einmal diejenige Organisation unterstützen, deren Existenz man einen Großteil seiner Tools und Produktivität verdankt?

Die Eclipse Foundation hat nun eine Möglichkeit geschaffen, mit der auch Einzelpersonen, an die Foundation direkt spenden können. Alles was man braucht ist eine Kreditkarte oder einen Paypal-Account. Das Spendenprogramm wird hier vorgestellt, die Spendenseite ist hier zu finden.

Man kann sich aussuchen ob man mit seiner Spende anonym bleiben will oder in einer Liste veröffentlicht wird. Spender mit einer Summe ab $ 35 können zum “Friend of Eclipse” werden. Diese können ein spezielles Logo verwenden und sie bekommen Zugang zu einem dedizierten Mirror-Server für ihre Downloads.

Das JSON Format (Java-Script Object Notation), ein leichtgewichtiges Format um Daten von einem Server zu einem Client (i.e. Browser) zu übertragen, welches beispielsweise gerne in AJAX-Anwendungen verwendet wird, ist von Natur aus nicht sonderlich lesbar.

Um die Lesbarkeit von JSON zu erhöhen gibt es ein Eclipse-Plugin (in einer sehr frühen Version), welches zum einen JSON in einer Baumstruktur darstellen kann. JSON kann auch als XML dargestellt und exportiert werden. Im weiteren ist es möglich die Validität von JSON Objekten zu überprüfen.

Das Plug-in steht bei Sourceforge zum Download bereit.

Seit ein paar Tagen ist der erste Release Candidate für Eclipse 3.2 und die komplementären Pakete, die als Callisto bezeichnet werden, verfügbar. Für das Callisto Komplettpaket (Eclipse SDK plus zehn wichtige Erweiterungen) gibt es keinen zusammen gefassten Download mhr, vielmehr muss man sich die Pakete, die man nutzen möchte selbst downloaden.
Der erste Eindruck ist sehr gut, Eclipse scheint nochmals einen Tick schneller geworden zu sein und die einzelnen Plugins haben dezente aber sinnvolle Erweiterungen erfahren. Auch optisch gibt es einige neue Elemente die Eclipse / RCP noch “attraktiver” machen.
Meine tagtäglich benutzte Sammlung aus Plugins läuft einwandfrei unter diesem Release, wobei ich sagen muss, dass ich schweren Herzens Xored Trustudio durch phpEclipse ersetzt habe, da die Zukunft von Trustudio momentan nicht allzu gut aus sieht (und Trustudio unter Eclipse 3.2 immer Schwierigkeiten gemacht hat).

Eine richtungsweisende Erweiterung für Eclipse / SWT hat das Apogée Projekt als Nebenprodukt herausgebracht. Das Apogée Projekt versucht auf Basis der Eclipse RCP (Rich Client Platform) ein Next Generation ECM (Enterprise Content Management) System mit gescheitem Desktop GUI für das Backend zu etablieren.

Im Rahmen der Entwicklungsarbeit ist die Apogée SWT XForm Enginge entstanden. Dabei handelt es sich um eine Engine, die dynamisch aus XForm XML Dateien SWT Formulare erstellt. Das Besondere dabei ist, dass die Eingaben in den SWT Formularen gegen ein XML Schema validiert werden können.

Langfristig interessant wird dabei sein, dass es zur Definition von SWT Formularen reicht, eine XML Datei (eben XForms) zu verwenden und dass Formulardefinitionen sowohl für Thin Clients und Rich Clients nur einmal deklarativ erstellt werden müssen.

Weitere Informationen zur SWT XForm Engine findet sich hier ebenso die Links zur Dokumentation und SVN Repository.

Neben Macromedia / Adobe Flex, das in der Version 2 frei verfügbar sein wird, gibt es ja auch noch das veritable OpenLaszlo als Alternative. Welcher Lösung man den Vorzug geben will muss jeder für sich entscheiden — beide Lösungen haben Vor- und Nachteile. Beide arbeiten ähnlich mit deklarativem XML für die Beschreibung des GUI und mit einer Scriptsprache für die GUI-Logik. Für beide Technologien gibt es eine IDE auf Eclipse Basis, wobei die Flex IDE deutlich fortgeschrittener und vollständiger ist — sie wird aber auch etwa $ 1000 kosten im Unterschied zur Laszlo IDE die frei verfügbar ist.

Bei Flex 2 scheinen die Komponenten wesentlich ausgereifter und schneller zu sein, was aber durch einen neuen Flashplayer erkauft wird, den es bis jetzt nur als Beta gibt und der auch seine Zeit benötigen wird um die proklamierte Ubiquität von Flash zu erreichen.

OpenLaszlo basiert auf Java-Script, das Erlernen von Action Script entfällt also. Auch rendert OpenLaszlo auch für ältere Flash Versionen mühelos.

Was aber OpenLaszlo als Vorteil mitbringt, dass es nicht auf Flash als Ausgabeformat festgelegt ist. In einer kommenden, nahen Version wird OpenLaszlo aus den Sourcen neben Flash auch DHTML und AJAX basierte Seiten erzeugen können. Die Beispiele sind verblüffend, beide Versionen gleichen sich fast vollständig, nur in einem Fall eben ohne(!) Flash und auch ohne proprietäres Plugin >> sehr cool!

Manchmal sind es diese kleinen, feinen Tools über die man eher stolpert als dass man sie gesucht hätte, die das Arbeiten extrem positiv vereinfachen. So bei uns geschehen mit Trac, das seither unverzichtbar bei der Arbeit geworden ist.

Trac ist ein integriertes SCM (Software Configuration Management) und Projekt Management Tool, das wirklich clever ist. Im Projekt Management Bereich können Milestones und Versionen avisiert werden, im Issue Tracking können Bugs und Feature Requests eingetragen und verwaltet werden. Dazu ist es noch ein Wiki in dem etwa die Dokumentation zu dem verwalteten Projekt gepflegt werden kann. Der Clou ist aber die Anbindung an SVN (Subversion) Versionierungswerkzeug. Der Entwickler kann bequem per Browser den Quellcodebaum durchforsten und sich Versionsstände ansehen.

Die Anbindung geht aber weiter: Versieht man etwa die Annotation beim Subversion Commit mit entsprechenden Kommentaren (etwa “Ticket #56 fixed”) erkennt Trac das automatisch und zeigt in der Timeline genannten Übersicht gleich an was gefixt wurde und verlinkt den SVN Eintrag mit der Bug Database.

Aber Trac ist noch viel mehr, seinen vollen Wert erkennt man erst in der Nutzung. Arbeitet man verteilt im Team gibt es nichts Aufschlussreicheres (auch kein Mail, IM oder Skype) als sich die Timeline anzusehen, die Issues, Bugs, Code Commits und Wiki Einträge zeitlich geordnet auflistet und jedem Beteiligten ad hoc Übersicht über den Projektstatus verschafft.
Trac macht aber auch Sinn, wenn man alleine arbeitet, alleine durch seine Fähigkeit, ein Projekt zu begleiten.

Trac ist Open Source und in Python geschrieben und es gibt auch eine Menge an Trac Hacks und Plug-ins für diejenigen, denen die Grundausstattung nicht genügt…