Ursprünglich eigentlich nur ein kleiner Tweet, wie immer etwas zugespitzt formuliert, mittlerweile aber dennoch als Blogpost geeignet, weil der Tweet zum einen die eine oder andere Antwort ausgelöst hat und zum anderen weil das Thema wichtig und kontrovers ist.

Ursprung ist ein Post von Larva Labs, die die Situation für Android-Entwickler beschreiben. Larva Labs ist ein kleiner Softwarehersteller, der Spiele und Anwendungen für Googles Android Mobile Devices OS herstellt. Zwei der Anwendungen (i.e. Spiele) waren unter den Top 10 des Android Market. Beide Anwendungen sind mit 5, bzw. 4,5 Sternen sehr gut bewertet und werden zu $ 4,99 verkauft.

So weit so gut. Das eigentliche Drama beginnt dann, wenn man schaut, was hinter den Zahlen steckt. Larva Labs haben mit den beiden Anwendungen gerade mal durchschnittlich $ 62,39 am Tag umgesetzt – ein Witz angesichts der Entwicklungskosten.

Ein weiteres Beispiel für die Probleme für den Android Entwickler Markt führen Larva Labs mit dem Spiel Trism auf. Während der Hersteller im Apple Appstore in den ersten zwei Monaten das Spiel mit einem Umsatz von mehr als $ 250.000 verkauft hat, hat er von der gleichen Software als Android-Port bis heute weniger als 500 Kopien verkauft, was in der Summe einen Gewinn von $1.046 darstellt. Merkt Ihr was?

Ich will jetzt gar nicht das Fass um die bessere Technologie aufmachen. Sowohl Apple als auch Google haben ausgereifte Entwicklungsumgebungen, Frameworks, Emulatoren und interessante Devices. Mir persönlich ist Java auch näher als Objective C, obwohl ich Stellvertreter der iPhone-Fraktion bin. Um was es jedoch geht, ist das Problem, dass man mit Android Software offensichtlich kein Geld verdienen kann – und das ist ein Problem!

Klar, man kann einwenden, dass die “Appstore-Zwerge” (Trademark für den Begriff liegt by Bits und so) mit ihrer Zulassungspolitik ein Risiko für Entwickler darstellen. Das ist natürlich ein Problem, aber Apple arbeitet an einer besser Kommunikation in dem Bereich. Außerdem überschreiten Apps, die nicht zugelassen werden oftmals die bekannten Grenzen, die Apple setzt. Aber auch wenn ein Restrisiko bleibt: Ein geregelter Markt ist immer noch besser als gar kein Markt – und das ist in der Diskussion das Entscheidende. Was nützt mir Freiheit (in weitesten Sinne) wenn ich von dem, was ich schreibe nicht die Miete bezahlen kann. Da kann Android noch so toll sein, aber nur mit Offenheit zieht man auf Dauer keine Entwickler an, die einem treu bleiben.

Mir ist auch klar, dass es auch im Appstore sehr, sehr schwer ist, Geld zu verdienen und praktisch nur die Anwendungen, die auf der Startseite promotet werden oder durch alternative Marketingmethoden zum Hype werden, wirklich rentabel sind. Ist ja auch kein Wunder, dass man bei > 50.000 Anwendungen leicht in der Masse untergeht. Aber es ist immerhin ein potentieller Markt vorhanden – und ein Marktplatz der ungleich attraktiver als der von Android ist. Das kann man auch als Hardcore-Androidianer nicht leugnen. Man kann versucht sein zu sagen, dass Android noch nicht da ist, wo es mal sein könnte. Unbenommen das stimmt, aber im gleichen Atemzug sollte man dann auch mal darüber nachdenken, wo Apple dann sein wird, wenn der Vorsprung jetzt schon so groß ist…

Der DevDusk findet diesmal nicht am 7. September, sondern bereits am 3. September ab 19 Uhr statt.

Aus gegebenem Anlass wollen wir das Treffen mit dem Gründungstreffen der Google Technology User Group zusammen fallen lassen.

Es wird einen sehr interessanten Vortrag über Android und über das neue Google Wave geben. Anschließend wird mit Hands-on Wave weitergemacht. Also bitte Notebooks mitbringen!

Für die Wave Hacks ist ein Wave Account nötig. Wer diesen noch nicht hat, sollte sich bis Ende August hier als Teilnehmer anmelden. Dann bekommt Ihr einen!

Die Veranstaltung findet wie gehabt in der Brotfabrik statt.

Um das etwas angestaubte grafische User Interface (GUI) von OpenOffice.org aufzumöbeln, wurde Ende 2008 das Projekt Renaissance gegründet.

Ziel war es, das GUI zeitgemäß zu gestalten. Einen ersten Entwurf gibt es jetzt bereits zu bestaunen und zwar nicht nur als Grafik sondern als Click-Dummy.

Das Neue GUI ist vollkommen in Java programmiert, so dass eine lokale JRE Installation ausreicht um folgendes Webstart / JNLP zu starten. Als Ergebnis des Downloads steht einem die Oberfläche mit Ribbons ähnlicher UI zur Verfügung. Leider ist es noch nicht vorhersehbar ob Java nur für den Click-Dummy benutzt wurde oder aber ob Java eine größere Rolle bei OpenOffice.org erhalten wird. Die Prototypenphase des Projekt Renaissance ist jedenfalls abgeschlossen und es ist anzunehmen, dass das neue UI in Serie geht.

Es bleibt spannend wie Projekt Renaissance dann im fertigen Produkt aussehen wird und ob Java einen dominanteren Part in OpenOffice.org erhält.

Wenn man einige Jahre Usergruppen leitet und auch als Vortragsreisender für bestimmte Technologien unterwegs war, also klassisch als unabhängiger technologischer Evangelist (klingt komisch auf Deutsch, soll aber Technical Evangelist übersetzt sein) wirkt, kommt es immer wieder zu ähnlichen Beobachtungen, denen ich in diesem Blogeintrag einmal nachgehen will.

Wenn ich eine Technologie als Usergruppenleiter oder unabhängiger Evangelist vertrete, tue ich dies aus der Überzeugung heraus, dass die Technologie gut, interessant und viel versprechend ist. Wenn ich meine Zeit in eine Technologie investiere, muss mir klar sein, dass ich diese Technologie auch selber nutzen und in Kundenprojekten einsetzen will und werde. Ich bin auf Seiten der Entwickler, die meine Veranstaltungen besuchen, weil sie aus erster Hand eines Entwicklers hören wollen, wie es sich mit dieser oder jener Technologie verhält.

Entspringt die Technologie oder das Projekt aber einer Firma, kommen ganz andere Interessen mit dazu. Der Firma geht es weniger um die Coolness oder die für Entwickler interessanten Dinge dabei, sondern es geht ihr letztlich darum, mehr Technologie und mehr Produkte zu verkaufen. Die meisten Firmen haben ihre eigenen bezahlten Evangelisten, deren Erfolg wird aber in der Zahl der “bekehrten” Entwickler oder aber schlicht in Verkaufszahlen gemessen. Einer solchen Erfolgskontrolle unterliegen freie Evangelisten nicht – sie tun es aus Überzeugung. Diese Authentizität lässt sich nicht kaufen, sie muss aus Überzeugung entstehen – genau diese aber ist es, die den Unterschied zu Veranstaltungen macht, bei denen immer auch mehr oder weniger Produktmarketing betrieben wird.

Ein weiterer Konflikt ist an der Stelle auszumachen, wenn Firmen mehrere Technologien haben, die miteinander arbeiten. Hier gilt aus Firmenperspektive die Devise des Cross-Sellings, also jene Frontend-Technologie arbeitet am besten mit dieser Backend-Technologie aus dem selben Haus zusammen oder diese Software passt exzellent zu der Hardware des gleichen Herstellers. Natürlich gibt es Alternativen aber einem Corporate Evangelist wird es vorwiegend um das Promoten der eigenen Technologien gehen. Hier sind freie Evangelisten wieder im Vorteil, sie werden das propagieren, was aus ihrer Erfahrung und Praxis heraus am meisten Sinn macht.

Eine Ausnahme für das hier beschriebene bilden die Usergruppen oder Veranstaltungen, die aus Community Projekten hervorgegangen sind und zumeist unter die Klassifikation Free and Open Source Software (FOSS) fallen. Hier verhält es sich anders, da im Unterschied zu Technologien und Projekten hinter denen Unternehmen stehen, keine Drittinteressen im Spiel sind.

Christian Heilmann – seines Zeichens Web Developer Evangelist für das Yahoo Developer Network – führt in seinem neuen Buch-Projekt Developer Evangelism aus, wie sich Corporate Developer optimal geben sollten, um einen maximalen Impact zu erzielen. Für freie Evangelisten, die Technologien aus Überzeugung promoten bietet das Buch weniger als für Corporate Evangelists. Geht man die Kapitel durch wird deutlich, dass diese aus Überzeugung für die Technologie auftreten müssen und nicht um Produkte zu verkaufen. Die Firma, für die man arbeitet muss in den Hintergrund treten, die Technologie muss im Mittelpunkt stehen:

Yes, you work for a certain company that builds a lot of products, some of them cool – some of them terrible. The point of developer evangelism is not to get people excited about the brand or the company behind it though.

Instead it is about the products the company releases and even more specifically about getting developers excited about playing with them.

Diese uns andere Einsichten Heilmanns sind diejenigen, die einen Evangelisten erfolgreich machen sollen. Natürlich gehört dazu auch ein Management, was diese Art von Evangelisation unterstützt – es ist eben ein allumfassender Lernprozess.

Freie Evangelisten sind hier im Vorteil: Vieles, was sich bei Unternehmensevangelisten ändern muss, ist bei ihnen sozusagen naturgegeben schon vorhanden. Die oben angesprochene Authentizität muss sich durch Begeisterung und Überzeugung für die Technologien speisen und aus nichts anderem sonst.

Entwickler sind selten Entscheider, aber sie sind öfter als man denkt Entscheidungsvorbereiter. Und wenn Entwickler von Technologien angesprochen sind steigt die Chance, dass das Management sich auch dafür entscheidet. Das Ziel von Unternehmensevangelisten, mehr Produkte zu verkaufen und mehr Entwickler für sich zu gewinnen, stellt sich so auch indirekt ein – aber ohne peinliche Marketing- und verkappte Promotionaktionen für Produkte.

Hier sind wiederum die freien Redner im Vorteil. Ihre Unabhängigkeit erzeugt auch die angesprochene Authentizität. Sie ist aber auch für die Unternehmen eine unberechenbare Komponente, weil deren Technologien zwar authentisch demonstriert und erklärt werden, aber nicht unbedingt auf die Art und Weise, wie es die Marketingabteilungen der Firmen gerne hätten. Unternehmen sollten diese Unberechenbarkeit aber nutzen, sie ist oftmals mehr Wert als gestreamlinte Marketingshows.

Es ist ein heisser Wettbewerb darüber entbrannt, welche die ideale Sprache nebst Java auf der Java Virtual Machine (JVM) sei. Der Wettbewerb hat sogar manchmal den Touch, welche Sprache der legitime Nachfolger von Java sei: Scala oder Groovy.

Beide Lager stehen sich gegenüber und predigen die Vorteile der eigenen Technologie. Das geht von der akademischen Ebene bis hin zum lockeren Podcast. Der Java Podcast Javaposse, hat eine eigene Scala Rubrik und einer der Macher – Dick Wall – muss sich als running Gag immer verteidigen, dass er kein Groovy Hasser sei – wobei aber offensichtlich ist, dass die Macher von Javaposse Scala für besser halten. Jüngst hat sogar James Strachan, der Erfinder von Groovy, in einem Blogeintrag geschrieben, dass er Groovy vermutlich nicht entwickelt hätte, wenn er seinerzeit schon von Scala gewusst hätte.

Vielen ist Groovy zu dynamisch, da kommt Scala mit seiner statischen Typisierung den Javaentwicklern sehr entgegen. Auch das funktionale Programmieren wird vielerorts als Vorteil empfunden.

Jetzt hat Dierk König, seines Zeichens Autor von Groovy in Action (GINA) auf Twitter fünf Mythen zu Scala veröffentlicht, die (be)merkenswert sind.

• Myth1 “#scala is like Java” No. It’s much different in syntax even more in concepts. Expect a long learning curve.
• Myth2 “#scala is simple” No. It’s powerful but complex.
• Myth3 “#scala actors solve all multicore issues” No. Only for a niche of mt issues they offer a good solution.
• Myth4 “#scala pattern matching is powerful” Yes! Complex but certainly powerful. I love it!
• Myth5 “#scala will replace Java” Not for me. My brain is not up to that task. I need a simpler lang, not a more complex one.

Natürlich nicht ganz objektiv, aber dagegen steht die Einfachheit und Dynamik von Groovy und die tatsächliche Ähnlichkeit der Syntax (die bis zur Identität reichen kann) zu Java.

I love the Groovy, Man!

Auf der Google Hausmesse Google I/O wurde eine Demo eines neuen Google Dienstes / einer neuen Anwendung gezeigt, die die Art und Weise wie wir elektronisch kommunizieren nachhaltig verändern könnte.

Google Wave vereint Email, Instant Messaging, (Micro-)Blogging, Collaborative Working und vieles andere mehr in einer Anwendung. Ein sog. Wave Objekt beinhaltet all diese Kommunikations- und Kollaborationsmöglichkeiten und ist das Zentrum der Anwendung. Folgt man der Demo kommt man aus dem Staunen nicht mehr raus. Neben der Integration von allen möglichen Diensten und der Verfügbarkeit einer API sind die Robots interessant, die einer Wave als Teilnehmer hinzugefügt werden können.

Wer Google Wave verstehen will, dem sei empfohlen sich 80 Minuten Zeit zu nehmen – es lohnt sich und man gewinnt einen Eindruck von der Zukunft der elektronischen Kommunikation. Die ganzen Möglichkeiten aufzuzählen ist kaum möglich, das muss man sich anschauen. Ergänzend ist dieses Interview mit Sergey Brin interessant sowie das Interview mit dem Kern des Google Wave Teams.

Eine kleine Kröte ist zu schlucken – das ist die Tatsache, dass die Anwendung auf HTML 5 aufsetzt. Google Wave wird dazu erst möglich, aber die Nutzer des Internet Explorers bleiben außen vor – Microsoft muss nun nachziehen.

Am Rande bemerkenswert ist die Tatsache, dass Google Wave als OpenSource verfügbar sein wird, der Dienst also nicht nur von Google sondern auch von anderen Unternehmen angeboten (und modifiziert) werden kann, sehr interessant. Weiterhin bemerkenswert ist, dass by Google nach der Devise “Eat your own dogfood” verfahren wird – der Client für Google Wave wurde komplett mit dem Google Web Toolkit erstellt.

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.

Wer mein Blog liest weiss, dass ich zu den mehr oder minder überzeugten Eclipsenutzern im IDE-Ringen zähle. Zend Studio und Flex Builder neben diversen anderen Editoren sind mein tägliches Werkzeug und ich arbeite im Großen und Ganzen gerne damit.

Aus diversen Anlässen heraus habe ich aber immer wieder mit NetBeans zu tun, sei es durch das Nutzen Groovy / Grails Plugins (was bei Eclipse schlicht nicht zu benutzen ist) oder die reine Neugierde, einfach einmal das PHP Plugin zu probieren. Auch durch die Möglichkeit sich über Netbeans die Entwicklung von JavaFX zu erleichtern, habe ich mich mit Netbeans intensiver beschäftigt.

Und siehe da, Netbeans ist in weiten Teilen konkurrenzfähig und in manchen Bereichen deutlich leistungsfähiger als die anderen IDEs. Vor allem wirkt die Netbeans-Entwicklung sehr agil und flexibel. Das Netbeans-Team geht sehr schnell auf Entwicklungen ein und implementiert sie in der IDE. So ist etwa der Ruby/JRuby Support in Netbeans legendär. Die Java-Tools sind ebenfalls mehr als brauchbar, der Swing-GUI-Builder Matisse etwa sucht noch seinesgleichen.

Der Groovy und Grails Support ist auch sehr vorbildlich (bitte den GSP Support in der nächsten Version berücksichtigen!) und auch PHP kann punkten. Der Unittest Runner und die in Version 6.7, Milestone 3 hinzugekommene Code Coverage, lassen den Wind für Zend deutlich eisiger werden. Mit PDT kann Netbeans sicherlich jetzt schon konkurrieren.

Wer viel mit Java-Script zu tun hat sollte sich einmal Netbeans ansehen, die Unterstützung ist nach Aussagen vieler besser als die von Aptana. Und wer mit Erlang, Scala oder Python programmiert wird mit Netbeans auch fündig werden.

Auch vom Handling geht mit Netbeans vieles einfacher. So ist etwa die Installation von Plugins eine Leichtigkeit. Alle verfügbaren Plugins stehen in einer Auswahlliste bereit und man braucht nicht einen halben Tag um alle Plugins, die man so braucht zusammen zu suchen.

Summa summarum ist Netbeans mittlerweile auch für den anspruchsvollen Entwickler eine IDE der Wahl. Wer “exotische” Sprachen nutzt wird hier ebenso fündig wie bei der Suche nach Support für die Mainstream Sprachen. Auch der Vorbehalt die Swing GUI sei langsam, stimmt so nicht mehr und unter Mac OS X sieht Netbeans ab Version 6.7 sogar regelrecht schick aus.

Netbeans ist also definitiv auf dem aufsteigenden Ast, seine Entwicklung und seine Nutzerzahlen gewinnen an Momentum. Man kann nur hoffen, dass durch die geplante Übernahme von Sun durch IBM diese hervorragende IDE Alternative nicht untergehen wird, denn IBM hat bereits eine IDE und das ist Eclipse.