Suche
Die Entwicklungsumgebung der Wahl

Kampf der Giganten: NetBeans, IntelliJ IDEA und Eclipse im Java-Tooling-Vergleich

Marco Schulz

© 2016 Noe Francisco Sosa Espinosa

Ganz gleich ob Privatperson oder professioneller Entwickler, die freien IDEs NetBeans, IntelliJ IDEA oder Eclipse erfreuen sich nach wie vor größter Beliebtheit. IntelliJ ist in dieser Runde zwar der Exot, da es sich um ein kommerzielles Produkt handelt. Allerdings bietet die kostenlose Community-Version genügend Funktionen, um sich in das Feld mit einreihen zu lassen. Alle drei Prüflinge haben sowohl ihre Stärken als auch Schwächen und sind im Großen und Ganzen mehr als nur einfache Editoren, um im Dschungel der Sourcefiles sichere Wege zu schaffen.

Für die tägliche Projektarbeit stellt sich weniger die Frage, welches die bessere Entwicklungsumgebung ist. Vielmehr wollen wir uns damit beschäftigen, für welche Anwendungsfälle optimale Ergebnisse zu erzielen sind. Gewichtiger gegenüber einem Füllhorn an Funktionalitäten ist die Benutzbarkeit (Usability), die sich aus den Punkten Stabilität und Übersichtlichkeit zusammensetzt. Dies sorgt im Tagesgeschäft für eine hohe Produktivität. Schließlich sollen Projektaufgaben abgearbeitet werden und nicht ein großer Teil der Aufwände in die Pflege der eigenen Werkbank fließen.

Aus persönlicher Erfahrung konnte ich in unterschiedlichen Projekten des Öfteren fragile Projektstrukturen gekoppelt mit falsch etablierten Prozessen beobachten. Diese Konstellation verursachte besonders in kritischen Phasen, beispielsweise zum Ende eines Releases, mit hoher Vorhersagbarkeit massive Schmerzen – bei allen Beteiligten. Die Palette der ungünstigen Entscheidungen reicht von der Auswahl instabiler Plug-ins, bis hin zu überfrachteten Arbeitsumgebungen oder Branch- und Merge-Strategien, die weit vom Standard entfernt sind.

Damit wir bei unseren Betrachtungen keine Äpfel mit Birnen vergleichen, ist es notwendig die Voraussetzungen zu normieren. Dabei gilt es sich an realen Bedingungen zu orientieren und keine Annahmen zu modellieren die mit der Wirklichkeit nur wenig oder nichts gemein haben. Nebenher reduziert das von mir beschriebene Vorgehen die Komplexität der Arbeitsumgebung.

Lesen Sie auch: Angular 2 IDE-Vergleich: IntelliJ vs. NetBeans vs. Eclipse

Aufstellung an der Startlinie

Dreh und Angelpunkt aller Bemühungen ist das Projektverzeichnislayout, mit der Festlegung wo Sourcen, Kompilat und Testdateien zu finden sind. Alle Kandidaten unterstützen das Build-Werkzeug Maven. Zudem ist Maven ein international etabliertes Tool, das in vielen Projekten Verwendung findet. Da das Hauptkonzept von Maven Convention over Configuration (CoC) ist, existiert für das Verzeichnislayout eine Vorgabe, der wir ebenfalls folgen wollen. Abbildung 1 zeigt die entsprechenden Strukturen.

Abbildung 01 - Maven Verzeichnislayout

Abb. 1: Maven gibt ein Verzeichnislayout vor, dem zu folgen sich lohnt

Die Ergebnisse des Build-Prozesses werden in das Verzeichnis-Target geschrieben. Dieses Verzeichnis sollte deshalb nicht mit unter ein Konfigurationsmanagement (Git, Subversion, etc.) gestellt werden. Die Datei pom.xml im Wurzelverzeichnis des Projektes enthält Build-Konfiguration und Projektdefinition. Die Ordner resources für Quelldateien und Testfälle sind im Maven-Kontext etwas Spezielles. Hier werden sämtliche Dateien abgelegt, die nicht zu den Java-Sourcen gehören. Das sind beispielsweise XML-Konfigurationen, Grafiken und so weiter. Eine sehr praktische Funktion ist das Anwenden von Filtern, die Textersetzungen im Build ermöglichen. Auch der Ordner site gehört zum Maven-Universum. In ihm befinden sich alle Fragmente, die benötigt werden, um konfigurierte Reports wie Checkstyle und Findbugs über Maven zu generieren. Anhand dieser Struktur und der Verwendung von Maven sind alle hier besprochenen IDEs in der Lage vorhandene Projekte zu importieren und automatisch sämtliche Einstellungen korrekt zu setzen. Es besteht keine Notwendigkeit, die durch die IDE generierte Projektkonfigurationen unter Versionierung zu stellen.

Im kollaborativen Arbeitsumfeld gehören Source-Control-Management-Systeme (SCM) wie Git oder Subversion zum Alltag. Auch wenn alle Kandidaten die wichtigsten Systeme unterstützen, sollte eine IDE-interne Nutzung von SCM tunlichst vermieden werden. Neben schlechter Performance gegenüber externen Lösungen wie Tortiose erfordern die IDE-Erweiterungen eine sehr genaue Arbeitsweise der Entwickler mit den Kommandos Add und Remove. Es kommt schnell einmal vor, das wichtige Dateien nicht in das Repository mit übertragen werden. Das hat dann wiederum schlechte Auswirkungen auf die Continuous-Integration-Umgebung (CI). Besonders bei sehr großen monolithischen Builds sind Compile-Zeiten von über einer Stunde nicht ungewöhnlich. Deswegen ist eine gute Build-Stabilität sehr gefragt.

Ein weiterer wichtiger Aspekt ist die Verfügbarkeit der IDEs für verschiedene Betriebssysteme. Sowohl für Windows als auch für Linux (z. B. Ubuntu [1]) kann auf den Internetseiten der Werkzeuge die entsprechende Installationsroutine herunter geladen werden. Dabei sei auch kurz angemerkt, dass es vorteilhafter ist, die Installationspaket von den Homepages zu verwenden, anstatt auf die Ubuntu Repositories zu setzen. Der Grund liegt in den veralteten und schlecht konfigurierten Paketen. Es sind einige manuelle Handgriffe notwendig, um der IDE die volle Stärke zu verleihen. Dazu gehört das Aktivieren der Plug-in-Repositories, um Funktionalitäten wie Maven, Bugzilla und andere nachträglich zu installieren.

Boxenstop

Um ernsthafte Projekte abarbeiten zu können, ist neben der Installation der Entwicklungsumgebung auch etwas Infrastruktur notwendig. Üblicherweise benötigen Entwickler zusätzlich lokal auf dem eigenem Rechner ein Datenbankserver (DBMS) und einen Applikationsserver. Die in der Produktion eingesetzten Applikationen kommen für diesen Anwendungsfall oft nicht in Frage, da meist die Lizenzkosten das Budget sprengen würden. Die Alternativen zu Oracle, IBM und BEA lauten hier oft MySQL, PostgreSQL, Tomcat, GlassFish oder Wildfly.

Auch wenn seit einigen Jahren, neben den etablierten Relationalen Datenbanken viele Speziallösungen auf den Markt gedrungen sind, die unter der Thematik NoSQL zusammengefasst sind, kommen die meisten Projekte mit einer MySQL-Standartinstallation, in der Entwicklungsphase aus. Mit aktuellen Technologien wie Hibernate und Spring lassen sich durch minimale Änderung in der Konfiguration die im Hintergrund arbeitenden Datenbanksysteme für den Produktivbetrieb nahtlos austauschen. Da für MySQL die Installation kinderleicht ist und unter Berücksichtigung der vorangestellten Überlegungen, soll dies das DBMS unserer Wahl sein.

Für die Laufzeitumgebung Webapplikationen soll der Servlet-Container Tomcat seinen Dienst verrichten. Gründe, die für Tomcat sprechen, sind im Vergleich zu einem Applikationsserver geringer Ressourcenverbrauch, gute Dokumentation und eine weite Verbreitung. Neben dem reinen Servlet-Container existiert noch ein Erweiterungsprojekt TomcatEE, das den ursprünglichen Tomcat mit Funktionen eines Applikationsservers erweitert. Wenn von vornherein bereits für die Entwicklung ein Applikationsserver zum Einsatz kommen soll, empfehle ich gern von RedHat Wildfly (ehemals JBoss) oder GlassFish von Oracle. Beide Server sind vollwertige frei verfügbare Java-EE-Applicationserver und lassen sich leicht installieren. Das Setup der NetBeans IDE bietet sowohl Tomcat als auch GlassFish bereits zur Installation mit an.

Licht im Dunkel mit Neon

Sehr leuchtstark präsentiert sich der Platzhirsch, Eclipse unter den Boliden. Meine Wahl des Downloads ist das JavaEE-Paket, das bereits mit einer guten Zusammenstellung an Werkzeugen für die Enterprise-Entwicklung aufwartet. Mit Neon ist eine weitere Version erschienen. Die Hauptmerkmale, die sicher einen Beitrag zum Erfolg von Eclipse beigetragen haben, sind einfache Erweiterbarkeit über das Plug-in-System und viele verfügbarer Plug-ins. Eine Installation der Software ist nicht notwendig, nach erfolgreichem Download ist das Archiv an einer beliebigen Stelle zu entpacken und kann direkt verwendet werden. Diese Eigenschaft gestattet es, die Umgebung zu personalisieren, erneut zu einem Archiv zusammenzupacken und weiterzugeben. Mit diesem Vorgehen gestalten einige Unternehmen ihre internen Prozesse, um einheitliche Strukturen zu etablieren. Aus Sicht des Konfigurationsmanagement und der Prozessorganisation werden andere Vorgehensweisen empfohlen. Der wichtigste Gesichtspunkt einer erfolgreichen Prozessautomation ist die Werkzeugunabhängigkeit. Gerade die vielen Möglichkeiten Eclipse den eigenen Wünschen anzupassen ist Fluch und Segen zugleich. Die Qualität der verfügbaren Plug-ins variieren drastisch zwischen hervorragend und bloß nicht verwenden.

Der Support während der Entwicklungsarbeit mit Codevervollständigung und Suggestions ist bei allen Kandidaten für die unterstützten Programmiersprachen ausgezeichnet. Werkzeuge die bei der Fehlerbehebung tatkräftig unterstützen sind mehr als Ausreichend vorhanden. Navigationen durch Source-Fragmente, Debugger und Profiler können mittlerweile als Basisausstattung betrachtet werden. Die initialen Schritte nach dem ersten Aufruf von Eclipse ist das Bekanntmachen des Datenbanksystems und des Applikationsservers. Dies lässt sich mit wenigen Handgriffen über die Assistenten der Views Server und Data Source Explorer erledigen. Neben der Option die Dienste zu starten und zu stoppen, kann auch direkt SQL ausgeführt werden. Bei großen Projekten ist es für eine flüssige Arbeitsweise in einigen Fällen notwendig der JVM etwas mehr Speicher zu gönnen. Um bereits während des Startvorgangs mehr Speicher zu allokieren, ist die Datei eclipse.ini zu editieren.

Lesen Sie auch: Eclipse Neon Highlights: Neun nette Neuigkeiten

Nach dem Import eines Maven-Beispielprojekts in den Arbeitsbereich der IDE präsentiert sich das Projektlayout im Package Explorer eher unaufgeräumt und verwirrend. Zudem lässt sich das Gefühl nicht loswerden, das es sich bei der embedded Maven-Version um eine für Eclipse adaptierte Variante handelt, mit einer eigenwilligen Interpretation. Der grafische POM-Editor unterstützt tatkräftig bei der Dependency-Verwaltung. Bei der Fehlersuche mit vererbten POMs ist die Sicht auf die Effective POM sehr nützlich. Die run-Konfiguration erlaubt größtmögliche Flexibilität, um das Projekt zu bereinigen, zu bauen, zu deployen und auszuführen.

Um die Qualität der Entwicklungsarbeit zu sichern, bietet Eclipse die View Markers, die über statische Codeanalyse potenzielle Probleme aufzeigt (Abb. 2). Detailliertere Informationen wie Test-Coverage oder das Erstellen der Java-API-Dokumentation lässt sich über Maven Site bewerkstelligen. Dazu muss die run-Konfiguration des Maven Builds adaptiert werden und als Argument Site für das Goal eingetragen werden.

Abbildung 02 - Qualitätssicherung in Eclipse

Abb. 2: Qualitätssicherung in Eclipse: Die View Markers zeigen potenzielle Probleme auf

Im Gesamteindruck besticht Eclipse mit seiner Funktionsfülle, die sich aber bei übermäßig viel installierten Plug-ins negativ auf die Performance und Stabilität der IDE auswirkt. Auch die Usibility bietet einiges Potenzial zur Optimierung. Um für das richtige Einsatzszenario eine ausgewogenen und stabile Arbeitsumgebung zu erhalten, bietet die Community spezialisierte Downloads an, die einer eigenen Zusammenstellung gegenüber bevorzugt werden sollten.

Power mit der vollen Röstung

Hinter NetBeans verbirgt sich kein geringerer als Oracle, die die Weiterentwicklung der Plattform vorantreiben. Auf der offiziellen Homepage heißt es, das NetBeans den besten Support der neusten Java-Technologien bietet. Ganz frisch steht die Version 8.2 zum Download, die eine Integration für Docker bietet. Dazu gehört neben einem Editor für Dockerfiles auch die Möglichkeit Images zu starten. Besonders überzeugt die IDE seit langen mit ihrem durchdachten Design. Nach dem Öffnen eines Maven-Projektes präsentiert der Projektexplorer die einzelnen Artefakte wohl geordnet. Schnell findet man sich zurecht und hat nicht das Gefühl durch Restriktionen der Umgebung behindert zu werden. Die Darstellung ist übersichtlich und macht Freude zum Arbeiten.

Ebenso wie für Eclipse biete NetBeans die Möglichkeit, Applikationsserver und Datenbank einzubinden. Abbildung 3 zeigt exemplarisch die Konfiguration des GlasFish-Servers. Dies bewerkstelligt man unter dem Reiter Services. An dieser Position finden sich noch weitere Dienste wie Docker und Selenium Server. Über den SQL-Editor erstellte Skripte lassen sich auf den konfigurierten Datenbanken ausführen. Das direkte Manipulieren der Daten einer Abfrage ist ebenso möglich (Abb. 4).

Abbildung 03 - NetBeans Server Einstellungen

Abb. 3: Exemplarisch die Konfiguration des GlasFish-Servers

Abbildung 04 - SQL Editor

Abb. 4: Über den SQL-Editor erstellte Skripte lassen sich auf den konfigurierten Datenbanken ausführen. Auch das direkte Manipulieren von Abfragen ist möglich

Zur Basisausstattung gehört neben Debugger, Profiler und Codeinspection auch eine History-Funktion, die zusätzlich zu den SCM Änderungen auch interne Zeitstempel vergibt. So können mittels einer grafischen und textuellen Diff-Ansicht schnell ältere Fragmente des Sourcecodes wiederhergestellt werden. Dank der Konventionen von Maven ist den Schaltflächen Clean, Build, Profile, Debug und Run bereits die korrekte Arbeitsweise hinterlegt. Mit einem Rechtsklick auf das Projektverzeichnis öffnet sich ein Menü, das es gestattet, individuelle Aktionen zu starten. So lassen sich die verschiedenen Maven Lifecycels bis ins kleinste Detail manipulieren.

Lesen Sie auch: Apache NetBeans am Scheideweg: Ab aufs Abstellgleis?

Bei der Bearbeitung von XML-Konfigurationen, wie sie bei Maven, Spring und Hibernate üblich sind, lässt sich bei vorhandenem XML-Schema die Datei über das Tastenkürzel ALT + SCHIFT + F9 zuverlässig validieren. Dieses kleine Detail kann sehr hilfreich sein. um abenteuerliche Suchen nach mysteriösen Fehlern zu verkürzen, die durch korrumpierte XML-Dateien entstehen können.

Im Gegensatz zur Eclipse Community ist die Auswahl der Erweiterungen für NetBeans eher beschränkt. Der Support von Android- oder BPMN-Projekten ist beispielsweise noch ausbaufähig. Der gewichtigste Unterschied zwischen NetBeans und Eclipse findet sich allerdings weniger im Funktionsumfang. In diesem Punkt stehen sich beide Kandidaten kaum in etwas nach. Ein Entscheidungsgrund für NetBeans ist vor allem die gute Performance und eine durchdachte Benutzeroberfläche.

Intelligentes Cockpit

Sehr elegant zeigt sich nach dem Öffnen das Dracula-Look-and-Feel in der kostenlosen Community-Edition der IntelliJ IDEA IDE. Das Darcula UI steht übrigens auch für NetBeans zur Verfügung. Auch diese Entwicklungsumgebung wartet mit allen Standardwerkzeugen auf, die für die Bearbeitung von Java-Dateien notwendig sind auf. Der gewichtigste Unterschied zur kommerziellen Version ist das Fehlen der Java-EE-Technologien. Das äußert sich unteranderem darin, dass das Einbinden von Applikationsserver und Datenbank nicht möglich ist. Beeindruckend ist, wie kinderleicht InelliJ mit sehr großen Dateien umgehen kann. Die Geschwindigkeit, mit der durch die einzelnen Source-Fragmente navigiert werden kann ist enorm und sucht Seinesgleichen.

Zum Starten des Maven Lifecycels existiert die View MavenProjects, welche die wichtigsten Goals der verschiedene Lifecycels aufrufen kann. Sehr übersichtlich ist die Aufbereitung der Source Analyse (Abb. 5). Über eine thematische Gruppierung lässt sich schnell entscheiden, welche Priorität einer möglichen Bearbeitung zugedacht werden kann. Auch erwähnenswert sind die integrierten XML Tools, mit denen aus einer bestehenden XML-Datei das zugehörige Schema erzeugt werden kann. Eine solche Funktion kennt man eher von dem hochspezialisierten XML-Editor XMLSpy von Altova.

Abbildung 5 - IDEA Codeinspection

Abb. 5: Die Codeinspection in IntelliJ ist übersichtlich

Ein weiteres Detail ist das Interaktive Terminal, das die durch das Betriebssystem bereitgestellten Kommandos (z. B. MSDOS) verarbeiten kann. In NetBeans erfordert diese Funktion die zusätzliche Installation von cygwin. Über eine Groovy- oder Kotlin-Konsole kann die IDE geskriptet werden. Damit steht eine Möglichkeit offen, individuelle automatisierte Prozesse umzusetzen. Die Wahl Groovy einzusetzen sichert zudem hohe Flexibilität und Plattformunabhängigkeit. So kann mit etwas Fleiß auch aus der eingeschränkten Community-Version ein eigenes Toolset entwickelt werden, das externe Services ansteuern kann.

Auch wenn man auf den ersten Blick mit IntelliJ einige Einschränkungen hinnehmen muss, bietet die IDE einige Überraschungen, die möglicherweise doch dazu anregen eine Lizenz der Enterprise-Version zu erwerben. Es ist durchaus ein verwendbares Werkzeug, mit vielen Detaillösungen, die Spaß machen entdeckt zu werden.

Fazit

Wie dieser Artikel gezeigt hat, ist es nicht zwingend notwendig hoch komplexe Arbeitsumgebungen zu konstruieren, um vorzeigbare und reproduzierbare Ergebnisse zu erhalten. Mit der Standardinstallation von Datenbank, Applikationsserver und SCM Client, dem Einsatz eines Buildtools wie Maven und der IDE seiner Wahl kann ein neuer Projektmitarbeiter innerhalb eines Tages Produktivität erreichen. Zudem ist es für viele Mitarbeiter sehr motivierend, wenn sie mehr Freiheitsgrade bei der Gestaltung der eigenen Werkzeugkiste haben.

Geschrieben von
Marco Schulz
Marco Schulz
Marco Schulz studierte an der HS Merseburg Diplominformatik. Sein persönlicher Schwerpunkt liegt in der Automatisierung von Build-Prozessen und dem Softwarekonfigurationsmanagement. Seit über zehn Jahren entwickelt er auf unterschiedlichen Plattformen Webapplikationen. Derzeit arbeitet er als freier Consultant und ist Autor verschiedener Fachartikel.
Kommentare
  1. Karsten Thoms2016-11-28 19:00:08

    Der Name Helios stammt nicht vom Edelgas Helium, sondern bezeichnet die Sonne (bzw. den gr. Sonnengott). Das Namensvoting ist hier zu finden:
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=271054

    Im Artikel haben sich gerade in den hinteren Teilen ein paar Typos eingeschlichen.

    Das Szenario ist auf JavaEE fixiert, aber für einen Projekttyp muss man im Sinne der Normierung halt entscheiden. Leider fällt dadurch flach, für welche Anwendungsszenarien eine IDE besser geeignet ist. Gerade auch bei den angesprochenen riesigen monolithischen Projekten (die man hoffentlich nicht hat, aber häufig genug existieren) kommen die IDEs kräftig und auf unterschiedliche Weise ins Schwitzen. Dass alle IDEs für kleinere Allerweltsprojektchen ähnlich gut performen darf man heute erwarten.

  2. Stefan Waldmann2016-11-29 10:53:22

    Schöner Vergleich!

    Beim Titel "Kampf der Giganten" hätte ich allerdings erwartet, dass am Ende auch ein Sieger gekürt wird. Im Fazit findet sich leider keine Spur davon.

    Übrigens heißt das Dark Theme von Idea nicht "Dracula" sondern "Darkula" - ein Wortspiel, das zwar mitunter auf den legendären Vampir hinweisen, aber gleichzeitig den "dunklen" Charakter des Themes (dark) unterstreichen soll.

  3. Stefan Waldmann2016-11-29 10:57:00

    ...ups, die korrekte Schreibweise des Themes (hab grad nachgesehen, allerdings in der Ultimate Version) ist Darcula.

  4. Melanie Feldmann2016-11-29 13:37:37

    Danke für die Hinweise! Sind korrigiert.

Schreibe einen Kommentar

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