Eclipse Insights: Unsere bevorzugten Eclipse-Einstellungen

Microservices mit Spring Boot, Spring Cloud und Docker

In diesem Tutorial wird man auf den Umgang mit Microservices vorbereitet. Eberhard Wolff erklärt zunächst, was Microservices eigentlich sind und mit welchen Chancen und Herausforderungen die Arbeit mit ihnen verbunden ist. Nachdem die Grundlagen etabliert wurden, erklärt er den Umgang mit der Container-Sofware Docker und den Umgang mit dem Spring Framework, die anhand eines Micoservices-Beispiels in der letzten Lektion noch einmal praktisch angewendet werden.

JETZT LOSLEGEN

Wie versprochen, erläutern wir nun die vorgenommenen Anpassungen im Vergleich zu den Standard-Eclipse-Paketen genauer. Wir möchten mit ein paar Standard-Einstellungen anfangen, die für das Profil angepasst wurden. Diese Einstellungen werden automatisch vorgenommen, wenn das Oomph-Profil verwendet wird, sodass Sie sie nicht für jede neue Eclipse-Installation erneut durchführen müssen. Natürlich ist es aber immer möglich, diese Einstellungen zu verändern oder mehr Standard-Einstellungen Ihrer Wahl hinzuzufügen. Vor zwei Jahren hat Holder Staudacher bereits eine wertvolle Liste mit beliebten Preference-Einstellungen präsentiert. Wir möchten nun die wichtigsten davon beschreiben, die es in das Oomph-Profil geschafft haben.

Native Hooks oder Polling

Eine der häufigsten Beschwerden von Eclipse-Nutzern bezieht sich darauf, dass Inhalte, die im Eclipse-Workspace angezeigt werden, manchmal nicht synchron mit dem File-System sind. Das passiert, wenn Änderungen an einer Datei außerhalb von Eclipse vorgenommen werden und die Datei danach in Eclipse weiterbearbeitet wird, ohne F5 zu drücken. Viele Nutzer wissen allerdings nicht, dass es dafür eine einfache Lösung gibt. Eclipse bietet zwei Einstellungen an.

Die erste aktualisiert automatisch den Inhalt des Workspace, wenn die Datei extern geändert wird. Die zweite führt ein automatisches Update beim Öffnen durch, für den Fall dass es Änderungen gab. Mit diesen zwei Einstellungen ist es nicht mehr nötig, F5 zu drücken, wodurch eines der lästigsten Probleme mit Eclipse gelöst ist. Natürlich sind beide Einstellungen Teil des EclipseSource Oomph Profils.

UTF-8

Eine andere Einstellung, die wohl jeder Eclipce-Entwickler schon mehrere hunderte Male geändert hat, ist die Codierung. In Zeiten der heterogenen Betriebssysteme wird typischerweise UTF-8 verwendet. Darum ist das der Standard in unserem Profil.

Zeilennummern

Über Zeilenummern in Editoren wurde in der Vergangenheit bereits ausgiebig diskutiert. Wir wollen diese Diskussion nicht erneut öffnen und aktivieren einfach die Zeilennummerierung standardmäßig für alle Editoren.

AWT-Pakete ignorieren

Funktionen wie Content Assist, Organize Imports und Quick Fix sind nützlich, um Arbeit beim Tippen zu sparen. Einige der Vorschläge sind aber nicht immer das, was man erwartet. Das kann daran liegen, dass Frameworks überlappende Namens-Schemata verwenden. Es gibt leider keine gute Standard-Lösung für diejenigen, die mit überlappenden Frameworks arbeiten müssen, außer der Verwendung von fortgeschritteneren Frameworks wie Code Recommender. Einige Dinge werden allerdings so gut wie nie verwendet, sodass es sinnvoll ist, die Pakete komplett aus dem entsprechenden Namespace zu entfernen.

Java AWT ist (in unserem Kontext) ein gutes Beispiel dafür. Es verursacht äußerst lästige Überschneidungen. Die Klasse “Composite” überschneidet sich mit der SWT Composite; die Klasse “List” mit Java. Da wir AWT in so gut wie keinem Projekt verwenden, haben wir entschieden, AWT komplett zu entfernen, sodass es nicht mehr im Content Assist oder Organzie Import erscheint.

Zu diesem Zweck stellt Eclipse sogenannte Type Filter zur Verfügung (Preferences -> Java -> Apperance -> Type Filters). Wenn Einträge zu dieser Liste hinzugefügt werden, werden alle entsprechenden Java-Klassen in den entsprechenden Features wie Content Assist, Organize Import und Quick Fixes verborgen. Wie der folgende Screenshot zeigt, können sogar Wildcards verwendet werden, um ganze Tress von Java Packages auszuschließen. AWT ganz zu verbergen ist eine Standard-Einstellung in unserem Oomph Profil.

Auch “java.lang.Object” wird häufig verborgen. Das ist allerdings zurzeit kein Standard in unserem Profil. Der Vorteil an diesem Ausschluss wäre, dass Methoden wie notify(), notifyAll() oder wait() nicht mehr angezeigt werden. Allerdings würden auch Dinge wie toString() fehlen. Natürlich können Sie aber jeden Filter selbst hinzufügen, den Sie brauchen und ihr Profil so ihren spezifischen Bedürfnissen anpassen.

Mehr Arbeitsspeicher für Eclipse

Die letzte Einstellung, die wir uns ansehen möchten, ist eigentlich keine Preference, sondern ein Start-Up-Parameter von Eclipse. Wenn Eclipse ohne Anpassungen gestartet wird, verwendet es maximal 512MB Arbeitsspeicher. Das hat vor 10 Jahren gut funktioniert, komplexe Projekte brauchen heute aber mehr Arbeitsspeicher. Moderne Entwickler-Rechner bringen normalerweise 4GB RAM oder mehr mit. Darum ist unsere Standard-Einstellung 2GB pro Eclipse-Instanz.

-Xmx 2048m

Keine Einstellungen für Warnungen, Formatter etc?

Warum gibt es keine Einstellungen für Dinge wie Formatter, Compiler Warnings, Save Actions und so weiter in dieser Liste? Wir empfehlen, diese Einstellungen projektspezifisch vorzunehmen. Dadurch werden sie mit dem Quellcode verteilt, nicht mit unserem Oomph-Profil. Statt diese Einstellungen im allgemeinen Preference-Dialog von Eclipse vorzunehmen, können sie per rechtsklick auf ein Projekt durchgeführt werden. Dort wird dann “Properties” ausgewählt und angegeben, dass die Einstellungen projektspezifisch sind.

Alle Einstellungen, die entweder den Compiler beeinflussen (z. B. Warnungen) oder den geschriebenen Code (z. B. der Formatter) sollten nicht für die Eclipse-Instanz vorgenommen werden, sondern über den Workspace für jedes Java-Projekt (oder -Bundle) einzeln. Dafür gibt es drei gute Gründe. Zum ersten unterliegen projektspezifische Einstellungen der Version Kontrolle. Dinge wie der Formatter haben direkten Einfluss auf den Code und sollten synchron mit der aktuellen Code-Basis sein, falls sie bearbeitet werden. Für verschiedene Zwecke, beispielsweise alten und neuen Code oder Test- und Non-Test-Code, können außerdem unterschiedliche Einstellungen sinnvoll sein. Zum zweiten werden projektspezifische Einstellungen direkt angewendet, wenn ein Projekt geöffnet wird. Sie sind unabhängig von den Einstellungen in der eigenen Eclipse-Installation des Betrachters. Zum dritten und wichtigsten gehören diese Einstellungen zum Projekt, nicht zu einer Eclipse-Instanz. Wenn  man an zwei Java Projekten arbeitet, die man aus zwei unterschiedlichen Open-Source-Projekten bezogen hat, können diese zwei unterschiedliche Formatter verwenden. Einen Formatter für die Eclipse-Instanz einzustellen würde in diesem Fall nicht funktionieren. Das gleiche trifft auf Warnungen zu, wenn sie nicht in einem projektspezifischen Kontext verwendet werden. Die Ergebnisse könnten dadurch bei anderen Mit-Entwicklern ganz anders aussehen. Darum sollte jedes Java-Projekt mit seinen spezifischen Einstellungen verteilt werden.

Es macht aber natürlich Sinn, die gleichen Einstellungen für mehrere zusammengehörige Java-Projekte zu verwenden. Open-Source-Projekte stellen beispielsweise häufig gemeinsame Projekt-Einstellungen für alle neuen Java-Projekte oder Bundles zur Verfügung, die im Kontext ihres Projekts entwickelt werden. Ein einfacher Weg, um projektspezifische Einstellungen von einem existierenden Java-Projekt auf ein Neues zu übertragen, ist das Kopieren des Inhalts des “.settings”-Ordners. Dieser befindet sich im Root-Ordner jedes Eclipse-Projekts. Alternativ enthält das Oomph-Projekt einige Tools um projektspezifische Einstellungen zu synchronisieren und unbeabsichtigte Abweichungen in den Einstellungen zu erkennen.

Wir hoffen, dass unsere Standard-Einstellungen gut für Sie geeignet sind. Beachten Sie aber bitte, dass Sie jede Einstellung jederzeit verändern können. Sobald sie die Preferences verändern, wird ein Fenster Sie fragen, ob sie die Veränderungen aufnehmen wollen. Wenn Sie das tun, werden sie in jede Ihrer künftigen Installationen übernommen. Wenn Sie denken, dass Ihre Anpassung für die meisten Nutzer interessant wäre, kontaktieren Sie uns bitte und wir überlegen dann, ob wir sie in das Original-Profil übernehmen wollen.

Sie können uns über dieses GitHub-Projekt Probleme melden und Feedback geben.

Im nächsten Teil unserer Kolumne werden wir einige der zusätzlichen Plugins beschreiben, die wir dem Oomph-Profil hinzugefügt haben.

Bis dahin, viel Spaß mit unserem EclipseSource Oomph Profile!

Im englischen Original erschienen auf dem EclipseSource Developer Blog, einem Blog über Eclipse-Technologien, Modellierung, RAP, Mobile-Entwicklung, sowie allgemeine Entwicklerthemen aus dem Java- und JavaScript-Umfeld.

Aufmacherbild: The eye of God Solar Eclipse von Shutterstock / Urheberrecht: Fernando Batista