Eclipse Feinjustage

Eclipse ist eine der führenden Entwicklungsumgebungen. Sie zu installieren, ist mit wenigen Handgriffen erledigt. Doch was kommt dann? Auch wenn die meisten Default-Einstellungen für den Einstieg in Ordnung sind, gibt es doch genug Stellschrauben, die einen detaillierten Blick wert sind. Ganz im Sinne des ORDIX Mottos "Best Practice" soll dieser Artikel einige bewährte Einstellungen aus dem Projektalltag aufzeigen.

Anfangs langsam

Einer der am häufigsten anzutreffenden Konfigurationsfehler in einem neu installierten Eclipse ist zu gering dimensionierter Speicher für die JVM. Die in diesem Fall typischerweise auftretenden Symptome sind "Trägheit der Oberfläche" und "Abstürze bzw. Einfrieren", womit die Eclipse-Sitzung zu Ende ist, bevor sie überhaupt richtig begonnen hat. Gerne treten diese Symptome auch nacheinander innerhalb einer Sitzung auf - ganz gemäß der Beschreibung eines Anwenders: "Erst wird es langsam und dann kracht es".

Abb. 1: Der Heap Monitor von Eclipse zeigt die Speicherreserven der JVM.

// Erstellen des Datasets -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m -vmargs -XX:MaxPermSize=128m -Xmx512m Abb. 2: Die eclipse.ini enthält wichtige Einstellungen für die JVM.

Abb. 3: Der Filterdialog der Problem View. Vergrößern

Abb. 4: Die Access Rules sind tief unten in der Buildpath-Konfiguration versteckt. Vergrößern

Abb. 5: Dank der Stepfilter hat der Entwickler beim Debugging immer seine eigenen Klassen im Fokus. Vergrößern

Die Trägheit deutet darauf hin, dass zu wenig Datenspeicher zur Verfügung steht und die JVM sehr häufig mit der Garbage Collection beschäftigt ist. Ob hier das Problem liegt, kann man sehr gut beobachten, indem der Heap Monitor aktiviert wird (Window ⇒ Preferences ⇒ General ⇒ Show Heap Status). Dieser zeigt den Füllstand des Speichers in Form eines kleinen Balkendiagramms in der unteren Statusleiste von Eclipse an (siehe Abbildung 1).

Es geht auch schnell

Die Abstürze bzw. das Einfrieren sind fast immer damit begründet, dass der Speicherbereich für Klassendefinitionen zu klein definiert ist. Da die Klassen erst bei Bedarf geladen werden, z. B. beim Öffnen einer View, die bisher noch nicht zum Einsatz kam, tritt das Problem sehr häufig beim Aufrufen einer neuen Perspektive auf. Diese löst das Laden mehrerer Views aus, obwohl kein Speicher mehr für das Laden der entsprechenden Java-Klassen vorhanden ist.

Die Lösung für diese beiden Probleme liegt in der Datei eclipse.ini, die im Installationsverzeichnis von Eclipse zu finden ist. Neben einigen Eclipse-spezifischen Parametern können dort auch die Laufzeitparameter der JVM eingetragen werden. Die entscheidenden Parameter sind -Xmx und -XX:MaxPermSize.

Ersterer setzt den maximal für Daten zu verwendenden Hauptspeicher der JVM. Letzterer dimensioniert den speziellen Speicherbereich PermGen, der beim Laden von Klassen verwendet wird. Abbildung 2 zeigt eine typische eclipse.ini. Eine Anmerkung zu dieser Thematik: Wie Abbildung 2 zeigt, hat das Eclipse-Projekt das PermGen-Problem bereits erkannt und eine eigene Lösung mitgeliefert (Parameter --launcher.XXMaxPermSize 256m). Leider tritt aber unter Windows in Kombination mit bestimmten Java-Versionen die Situation ein, dass dieser Parameter ignoriert wird. Es bleibt zu hoffen, dass dieses Problem in Zukunft behoben wird und Abstürze aufgrund von Speichermangel dann endgültig der Vergangenheit angehören.

Zwangspausen mangels Internet

Die Validierung von Markup-Dokumenten (XML, HTML) ist eine praktische Funktionalität. Durch farbliche Markierungen wird der Anwender direkt auf Probleme hingewiesen. Die Validierung basiert dabei auf DTD- bzw. XSD-Dokumenten, auch Descriptoren genannt, die den validen Aufbau eines Markup-Dokuments beschreiben. Welcher Descriptor zum Einsatz kommt, wird im Kopfbereich des Markup-Dokuments beschrieben. Zur Tücke wird dies, wenn diese Definition auf eine Position im Internet verweist.

Zwar ist Eclipse technisch durchaus in der Lage, den Descriptor aus dem Internet zu laden, aber nicht immer ist dies auch innerhalb von Firmennetzen möglich. Insbesondere wenn gar kein Internetzugang zur Verfügung steht, DNS-Anfragen aber weltweit möglich sind, kommt es häufig zu Problemen. Es scheint, dass Eclipse hängt bzw. abgestürzt ist, tatsächlich wird aber auf ein Timeout für die Anfrage des Descriptors gewartet.

Weniger Prüfungen, mehr Geschwindigkeit

Da dieses Problem auch noch bei korrekt eingetragenem Proxy innerhalb von Eclipse auftritt, liegt die Vermutung nahe, dass noch nicht alle Teile von Eclipse die Proxy-Konfiguration berücksichtigen. Ein Workaround für dieses Problem ist das Abschalten der Validatoren.

Dies geschieht über den Konfigurationseintrag "Validation". Dort können die Validatoren für die einzelnen Dokumententypen (de-)aktiviert werden. Zusätzlich bietet dieser Dialog die Checkbox Suspend all Validators an. In der Praxis hat sich das Deaktivieren aller Validatoren sowie das anschließende Auswählen der zuvor genannten Suspend-Checkbox bewährt. Die Funktionalität der Validierung geht dabei zwar verloren, aber eine syntaktische Prüfung erfolgt auch weiterhin. Zum Beispiel wird ein fehlendes Tag innerhalb einer XML-Datei auch weiterhin vom Editor erkannt und angemerkt.

Viele Warnungen in der Problem View

Größere Projekte haben die Eigenschaft, dass sie sehr viele Warnungen produzieren. Sei es, weil Eclipse die Rechtschreibung nicht mag, weil der Einsatz von nicht typisierten Collections seit Java 1.5 zu Warnungen führt, oder weil tatsächlich problematische Stellen im Code identifiziert wurden. Die Rechtschreibprüfung ist in einer IDE nicht die Kernfunktionalität und lässt sich schnell über den Haken "Window ⇒ Preferences ⇒ General ⇒ Editors ⇒ Text Editors ⇒ Spelling ⇒ Enable Spellchecking" deaktivieren. Alle anderen erkannten Probleme bleiben - kurzum: Die Problem View ist eigentlich in jedem Projekt gut gefüllt. Zwar sollte Quellcode stets ohne Warnungen vorliegen, doch dieses Ideal zu erreichen, ist nicht immer möglich. Warnungen gänzlich zu ignorieren, ist aber auch keine Lösung. Manche sind äußerst sinnvoll und weisen auf reale Fehler hin - wenn sie nicht in der Masse der Warnungen untergehen.

Selektive Sichtweise

Damit hier nicht der Überblick verloren geht, lässt sich die Problem View auf die eigenen Vorlieben anpassen. Eine interessante Möglichkeit ist es, die View auf das gerade im Resources Tree ausgewählte Element und wahlweise seine Unterelemente zu beschränken. Damit lassen sich dann Fragen wie z. B. "Welche Probleme hat dieses Package?" sehr einfach beantworten, indem man im Baum das entsprechende Package auswählt. Gleichzeitig werden in dieser Einstellung für Blattelemente des Baums (z. B. alle Klassen) nur noch die in ihnen gefundenen Probleme angezeigt. Abbildung 3 zeigt den Filterdialog mit der benötigten Einstellung.

Zugriffsregelung

Eine weitere, gut versteckte Hilfe sind die Zugriffsregeln für einzelne Bibliotheken. Mit Hilfe der Regeln kann der Zugriff auf bestimmte Klassen oder Pakete verhindert werden. Einmal konfiguriert, generieren diese Regeln Fehlermeldungen bzw. Warnungen, wenn Klassen verwendet werden, die auf das entsprechende Muster einer Regel passen. Als Anwendungsbeispiel sei hier die Umstellung des verwendeten Logging Frameworks eines Projekts von log4j auf commons-logging genannt.

Abbildung 4 zeigt die entsprechende Filterkonfiguration. Die Verwendung von Klassen aus dem Paket org.apache.log4j wird verboten (forbidden) und ein Fehler in den entsprechenden Klassen der Anwendung angezeigt. Der Vorteil dieses Ansatzes im Vergleich zu einem projektweiten Suchen und Ersetzen ist die Nachhaltigkeit. Während ein Ersetzen nur den Code zum aktuellen Zeitpunkt umstellt, verhindert der Einsatz von Access Rules auch die zukünftige, versehentliche Verwendung dieser Klassen.

Step-Filter

Das Debugging von Anwendungen beginnt häufig mit der Suche nach den interessanten Code-Abschnitten. Dazu muss der Code ab einem Einstiegspunkt schrittweise untersucht werden. Ein Problem stellen die Klassen und Methoden der Java API dar, die bei diesem Stepping zwangsweise mit besucht werden müssen. Als Beispiel sei hier die einfache Codezeile if (aString.size() >= 5) doSomething(); anzunehmen. Der interessante Teil ist der Aufruf von doSomething(). Beim Stepping erfolgt aber zunächst ein Aufruf von size() und erst dann doSomething(). Man kann aus dem Aufruf von size() mit einem Step-Back direkt zurückspringen und den Aufruf von doSomething() starten. Da dieser Vorgang aber für jede Iteration wiederholt werden muss, wünscht man sich schnell eine bessere Lösung.

Die eigenen Klassen im Fokus

Diesem Wunsch kommt Eclipse mit seinen Step-Filtern nach. Unter "Java ⇒ Debug ⇒ Step Filtering" in den Eclipse-Einstellungen können Pakete und Klassen bestimmt werden, die beim Stepping übersprungen werden. Abbildung 5 zeigt die im Lieferumfang von Eclipse enthaltene Auswahl. Eine Erweiterung um zusätzliche Pakete und Klassen ist durch den Anwender ebenfalls möglich.

Ist der Step-Filter aktiviert, werden Methoden der in diesem Dialog ausgewählten Klassen und Pakete beim Stepping automatisch übersprungen. Im Beispiel würde das Aktivieren des Step-Filters für java.* bewirken, dass die VM erst beim Einsprung in doSomething() anhalten würde. Die umständliche Zwangspause in size()entfällt für den Anwender.

Versteckte Schätze

Der Einstieg in die Java-Entwicklungsumgebung Eclipse fällt in der Regel sehr leicht. Doch dass die IDE häufig in ihrer Grundkonfiguration Probleme mit dem Speichermanagement hat, kratzt immer wieder am Image. Auch die schiere Masse an Einstellungsmöglichkeiten macht es schwer, die besonders nützlichen Funktionen auf Anhieb zu erkennen, denn sie bleiben bei flüchtigem Hinsehen verborgen.

So haben uns die hier vorgestellten Einstellungen in der Praxis weitergeholfen - aber erst nachdem wir aktiv nach ihnen gesucht haben. Meist sind es die Probleme des Entwickleralltags, die uns dazu zwingen, die IDE einmal näher zu betrachten. Ein Grund mehr, sich immer wieder mit den Möglichkeiten und Einstellungen näher zu beschäftigen, nicht nur - aber gerade auch - nach einem Versionswechsel.

Seitenanfang

Seite drucken

Seite weiterempfehlen