Suche
Eine persönliche Retrospektive zu Eclipse im Allgemeinen und Luna im Besonderen

Mein Eclipse-Luna-Jahresrückblick

Holger Voormann

© shutterstock.com/solarseven

Neue Webseite. Neues Logo. Java-8-Unterstützung. Das alles wird den meisten auffallen, wenn sie Eclipse 4.4 herunterladen und ausprobieren. Für viele wird die Java-8-Unterstützung neben kleineren Verbesserungen vermutlich der Hauptgrund sein, auf „Luna“ zu aktualisieren. Doch Luna hat noch mehr zu bieten, und die Java-Entwicklungsumgebung ist nur ein kleiner Teil davon: Auf die Früchte von 71 der 76 Luna-Projekte würde man bei der ausschließlichen Verwendung von Eclipse Standard 4.4 verzichten. Diese 76 Projekte – beziehungsweise 120, wenn man ihre Unterprojekte mitzählt –, die dieses Jahr innerhalb des Simultaneous Release Luna gemeinsam ihre Software veröffentlichen, sind wiederum rund die Hälfte aller Eclipse-Projekte. 

Die Website eclipse.org erfuhr nicht nur optisch, sondern auch strukturell eine Überarbeitung. Die Working Groups, Industrieverbände innerhalb der Eclipse Foundation, die bisher nur auf der Startseite ganz unten zu finden waren, rückten neben Tools und Projekten als einer der drei Hauptbereiche in den Fokus. Den neuen Look auf alle Eclipse-Webseiten zu übertragen wird noch einige Zeit in Anspruch nehmen. Technisch zu verschieden sind die teils statischen, teils erzeugten Seiten, zu denen auch das Wiki, das Bug-Tracking-System etc. gehören.

Der Weg zum neuen Logo

Ein wesentlicher Bestandteil des neuen Looks ist das modernisierte Logo. Der erste Versuch, das Logo zu erneuern, scheiterte Anfang 2010. Anfang 2014 wagte Ian Skerrett einen neuen Anlauf. Im Gegensatz zum ersten Versuch folgte nach der Auswahl aus einer Vielzahl von Vorschlägen noch eine Phase, in der eine Feinabstimmung basierend auf geäußerter Kritik erfolgte. Was die Schrift und die Farben betrifft, wurde in dieser Phase auch von der Möglichkeit Gebrauch gemacht, mehrere Vorschläge zu kombinieren (siehe Abb. 1).

Hinweis: Dies ist eine stark gekürzte Version des Leitartikels, der im Eclipse Magazin 5.14 erschien. In der Ausgabe mit Schwerpunkt auf dem Simultanrelease „Luna“ finden Sie außerdem weitere interessante Beiträge zu vielen der hier erwähnten Projekte.

Java-8-Unterstützung

Um die Zeit zwischen dem Release von Java 8 im März und dem von Luna im Juni zu überbrücken, wurden auf der Download-Seite unter dem Reiter Java™ 8 Support erweiterte Kepler-Pakete angeboten, die laut Download-Zahlen aber nur wenig Beachtung fanden. Mit „erweitert“ ist hier die Java-Entwicklungsumgebung, also die Java Development Tools (JDT), gemeint: der Eclipse-eigene inkrementelle Compiler, der Debugger, der Editor mit Autovervollständigung, mit Anzeige von Fehlern, Warnungen und Quick-Fixes (Abb. 2) sowie der Formatierer. Auch wenn es getrennte Einstellungen der Java-Version für Quelltext und der Java-Version für den erzeugten Bytecode gibt, ist es leider nicht möglich, aus Java-8-Quelltext mit Lambda-Ausdrücken Java-7-Code zu erzeugen.

Abb. 2: Per Quick Fix (Strg+1) lassen sich einzelne oder per Clean Up (SOURCE | CLEAN UP...) alle funktionale anonyme Klassen in Lambda-Ausdrücke oder umgekehrt umwandeln.

Ab Luna beherrschen auch die API Tools den Umgang mit Java-8-Code. Sie zeigen Fehler/Warnungen an, wenn man sich nicht an die Vorgaben von Schnittstellen fremder Plug-ins hält oder wenn man bei eigenen Plug-ins vergisst, die Version gemäß der semantischen Versionierung zu erhöhen – dazu ist das vorige Setzen einer Baseline der zu überwachenden Plug-ins in ihrer Basisversionen notwendig. Die API Tools sind Teil des Plug-in Development Environment (PDE) und damit in allen Java-Entwicklungs-Paketen vorhanden außer der Eclipse-IDE for Java Developers, die für die reine Java-Entwicklung ohne OSGi gedacht ist.

Abb. 3: Content Assist ohne (links) und mit Code Recommenders (rechts)

Auch Code Recommenders funktioniert mit Java 8 wie mit allen anderen Java-Versionen: In der Autovervollständigung werden die populärsten Einträge in der ansonsten alphabetischen Liste ganz nach oben gepuscht und um Prozentangaben ergänzt (Abb. 3). Neben der innovativen Autovervollständigung bietet Code Recommenders wie bisher die API Docs View, die mehr Informationen als die alteingesessene Javadoc View bietet. Neu hinzugekommen ist Snipmatch: Im Java-Editor erscheint beim Tastaturkürzel Ctrl+Alt+Leertaste ein Suchfeld zum Suchen von Code-Schnipseln (Abb. 4). Man kann eigene Snippets erstellen und diese der Allgemeinheit zur Verfügung stellen. Ich bin gespannt, wie stark sich der Nutzwert durch Qualität und Quantität der Snippets durch die Community ändern wird.

Abb. 4: Code Recommenders neuer Snipmatcher (Tastaturkürzel: Alt+Leertaste)

Xtend bezeichnet sich ebenfalls als „Java 8 ready“, verwendet aber für Lambda-Ausdrücke eine eigene Syntax. Damit entfernt sich Xtend, das Java beispielsweise dadurch vereinfacht, dass Typisierung weggelassen werden kann, mehr von Java. Während die Vereinfachung von Xtend auf einer anderen Syntax beruht, ergänzt Object Teams Java durch ein Konzept mit Teams und Rollen.

Auch die Analyse-Werkzeuge mussten teilweise fit für Java 8 gemacht werden. Erfreulicherweise kann man – dank unverändertem Heap-Dump-Format – weiterhin mit dem Memory Analyzer (MAT) auf die Jagd nach Speicherlecks in Java-8-Anwendungen gehen und den Speicherbedarf optimieren. Die Luna-Version 1.4 bringt kleinere Verbesserungen und hat mit riesigen Heap Dumps keine Probleme mehr. Außerhalb von Luna und offiziellen Eclipse-Projekten kommt EclEmma zur Messung der Testabdeckung bereits auch mit Java-8-Code zurecht. Bei FindBugs zur Fehlersuche mit Anti-Patterns muss man noch auf die kommende Version 3.0 und bei Checkstyle (ebenfalls zur Fehlersuche mit Anti-Patterns) voraussichtlich noch bis August warten (Update: FindBugs 3.0 RC1 wurde gerade veröffentlicht).

Verdunkelte IDE, geteilte Editoren und mehr

Abb. 5: Die dunkle Variante ist abhängig von der gewählten Darstellung des Betriebssystems (hier am Beispiel von Windows 7 mit hellem Standard- und dunklem „Steam VS“-Design).

Die Oberfläche der Eclipse IDE lässt sich mit dem so genannten Dark Theme auf dunkel umschalten: im Menü Window | Prefercences im Bereich General | Appearance das Theme Dark wählen. Das MoonRise UI Theme von Andrea Guarinoni diente bei der Entwicklung des Dark Theme als Grundlage. Weil sich aber die Farben beim Eclipse-eigenen Standard Widget Toolkit (SWT) bei Scrollbalken, (Kontext-)Menüs, Dropdown-Menüs etc. nicht verändern lassen, sondern vom Betriebssystem bestimmt werden, sieht das nur gut aus, wenn man auch im Betriebssystem ein dunkles Design gewählt hat (Abb. 5). Bei einigen Nicht-Plattform-Symbolen, wie die von JDT, gibt es aufgrund der für hellen Hintergrund optimierten GIFs ohne Teiltransparenz beim Dark Theme noch unschöne Blitzer (helle Pixel an den Kanten). Die Icons der Plattform dagegen sehen perfekt aus. Sie wurden alle im Vektorgrafikformat SVG neu erstellt, um daraus die erforderlichen PNGs zu erzeugen, die dank Teiltransparenz gleichermaßen mit hellen als auch dunklen Hintergründen harmonieren (siehe Abb. 6).

Abb. 6: Das Run-Icon in den Formaten GIF, PNG und SVG im Vergleich

Über eine weitere kleinere Verbesserung in Luna werden sich viele freuen: Der über zwölf Jahre alte Wunsch, Texteditoren horizontal oder vertikal splitten zu können, wurde in Eclipse 4.4 endlich erfüllt. Über das Menü ist der Split-Editor per Window | Editor | Toggle Split Editor (Horizontal) beziehungsweise Toggle Split Editor (Vertical) zu erreichen. Per Tastaturkürzel kann der Editor mit Strg+_ beziehungsweise Strg+{ gesplittet werden.

Es gibt nur drei Einträge im Bug-Tracking-System, für die jeweils mehr als 200 votiert haben. Neben dem Split-Editor sind das: Word-Wrapping (Umbruch von Zeilen, die über den sichtbaren Bereich ragen würden) und eine bessere Handhabung von besonders verschachtelten Projekten. Für Word-Wrapping gibt es bereits einen Lösungsvorschlag von Florian Weßling, über den ich in meinem letzten Jahresrückblick berichtet habe. Leider wurde er aber bisher – was ich frustrierend finde – nicht übernommen. Dagegen hat es der Mechanismus zum Umschalten der Sprache während der Laufzeit der von der Plattform angeboten, aber noch nicht von der IDE genutzt wird, in Eclipse 4.4 geschafft.

Verbesserungen außerhalb der IDE

Seit Kepler gab es vier Releases bei den beiden Geschwisterprojekten Java Implementation of Git (JGit) und Eclipse Git Team Provider (EGit). Die Version stieg von 3.0 auf 3.4. Die neue Git Interactive Rebase View wird für Git-Profis interessant sein. Ich dagegen freue mich, dass man nun in der History View Commit-Messages nachträglich ändern kann (Version selektieren und Rechtsklick: Modify | Reword). In der Git Staging View kann man Dateien auch nur teilweise committen. Das ging zwar schon in Kepler, aber davon wusste kaum jemand. Die im Vergleich zu Git etwas in die Jahre gekommene Versionsverwaltung Subversion (SVN) wird von Subversive bedient. Subversive macht mit Luna den Sprung auf Version 2.0. Es gibt nun Unterstützung für SVN 1.8, und die Programmierschnittstelle wurde geändert.

Abb. 7: Die Terminals View mit Tabs auf zwei Ebenen: neue Terminals werden innerhalb der View oder – falls die View gepinnt ist – in einer neuen View angezeigt

Nicht vier wie bei JGit/EGit, aber immerhin zwei Releases gab es beim C/C++ Development Tooling (CDT)-Projekt. In Version 8.3 kam die Unterstützung für die C++-Klassenbibliothek Qt hinzu, in Version 8.4 folgten einige Verbesserungen beim Debugger, z. B. „C/C++ Dynamic Printf“-Breakpoints, eine grafische Anzeige in der Trace Control View oder die Tatsache, dass der Debugger jetzt auch als eigenständige Applikation gestartet werden kann. CDT 8.4 läuft nicht mehr mit Eclipse 3.x, sondern nur noch mit Eclipse 4.x. Nicht nur für C/C++-Entwickler interessant ist die neue Terminals View (Abb. 7) des Target Communication Framework (TCF)-Projekts, einem Unterprojekt von CDT. Mit der Terminals View, die auch separat installiert werden kann (via Marketplace oder unter Help | Install New Software…  bei Work with „Luna“ auswählen, um General Purpose Tools | TCF Terminals (Console) View zu selektieren), kann man auf die Kommandozeile des lokalen oder per SSH, Serial oder Telnet auf die von entfernten Rechnern zugreifen. Die Terminals View ersetzt das bei Entwicklern so beliebte Programm PuTTY. Wer auf Linux entwickelt, sollte sich auch die Linux Tools mit den vielen verschiedenen Werkzeugen und viel Neuem in Version 3.0 anschauen.

Den größten Versionssprung zwischen Kepler und Luna hat die Web-IDE Orion gemacht: von 3.0 auf 6.0. Nur Sapphire, eines von mehreren Oberflächen-Frameworks in Luna, hat von 0.6.2 auf 8 eine noch längere Strecke zurückgelegt. Das zählt allerdings nicht, weil die Versionen zwischen 0.7.3 und 8 ausgelassen wurden. Bei Orion dagegen gab es die Version 4.0 und 5.0 tatsächlich. Doch selbst Zwischenversionen alle sechs Wochen sind dem Orion-Team, das bereits über Continuous Delivery nachdenkt, zu langsam.

71 – 3 + 8 = 76

Luna besteht aus 76 Projekten, fünf mehr als beim Vorjahres-Simultanrelease Kepler (s. Abb. 8). 68 der 71 Kepler-Projekte gibt es auch in Luna, acht kamen hinzu, drei fehlen. Die drei Abgänge, denen als Eclipse-Projekt die Archivierung droht, sind:

  • Die Agent Modeling Platform
  • Die SCA Tools (Service Component Architecture Tools), ein Unterprojekt des Top-Level-Projekts SOA Platform (Serviceorientierte Architektur),
  • EclipseLink

Viele der acht Eclipse-Projekte, die zum ersten Mal beim Simultaneous Release dabei sind, verwenden oder ergänzen das Eclipse Modeling Framework (EMF):

  • Sirius
  • EMF Client Platform
  • EMFStore
  • Business Process Model and Notation (BPMN2)
  • BPMN2 Modeler
  • Paho
  • QVTd (QVT Declarative)
  • XWT

 Abb. 8: Luna ist das Simultaneous Release mit den bisher meisten Projekten

Extrajavarestrisch

Die Anzahl aller Eclipse-Projekte stieg im gleichen Maß wie die der am Simultaneous Release teilnehmenden Projekte. Wechselten in den letzten Jahren vermehrt Projekte zu Eclipse, die wie Hudson und Vert.x nicht auf OSGi/Eclipse basieren, so gibt es nun erstmals auch Eclipse-Projekte, die nicht in Java geschrieben (oder wie Dash Infrastruktur-Projekte) sind. Bei Orion liegt der Schwerpunkt zwar auch nicht auf Java, sondern auf JavaScript, aber der Eclipse-basierte Server verpackt den JavaScript-Client-Code und ermöglicht so die Teilnahme an Luna. Um beim Simultaneous Release teilnehmen zu können, muss die Software nämlich aus Eclipse-Plug-ins bestehen. Das ist auch der Grund, warum Hudson nicht bei Luna dabei ist.

Vier solcher Nicht-Java-aber-Eclipse-Projekte sind seit Ende 2013, Anfang 2014 dazugekommen: Ponte, Mosquitto, Krikkit und mbeddr. Letzteres sind Domain-spezifisch erweiterbare Sprachen und eine Entwicklungsumgebung für den Embedded-Bereich, die auf JetBrains Meta Programming System (MPS) basiert.

En vogue: Das Internet der Dinge

Die anderen drei neuen Nicht-Java-Projekte sind aus dem Bereich Internet of Things (IoT), der bei Eclipse bis Anfang des Jahres noch Machine-to-Machine (M2M) hieß. Aus der M2M Working Group wurde die IoT Working Group mit neuer Adresse und neuem Logo. IoT boomt. Wegbereiter sind Kleinstrechner wie Raspberry Pi, stromsparende Funktechnologien wie Bluetooth 4.0 und 3-D-Drucker, die die fehlenden Teile liefern, um Sensoren und Aktoren mit der physischen Welt zu koppeln. Neue Hardware und neue Einsatzszenarien verlangen neue Software – Goldgräberstimmung auch bei Eclipse.

Einen großen Fang für IoT konnte Eclipse mit dem bekannten Open-Source-Projekt openHAB zur Gebäudeautomatisierung machen, das auf dem OSGi-Framework Equinox von Eclipse läuft. Aus openHAB, beziehungsweise wesentlichen Teilen davon, wurde Ende 2013 Eclipse SmartHome. Jetty, Hudson, Vert.x und nun openHAB/SmartHome – einige der Projekte waren schon groß, bevor sie zu Eclipse kamen. Einen weiteren guten IoT-Fang machte die Eclipse Foundation mit Benjamin Cabé, der sich selbst als „IoT Evangelist“ bezeichnet. Ohne Benjamin gäbe es die zweitägige EclipseCon France nicht, auf der das Thema IoT nicht zu kurz kommt. Außerdem ist er noch Projektleiter zweier IoT-Projekte.

Was wird aus der IDE und der Plattform?

Im Gegensatz zur JavaScript-basierten Web-IDE Orion mit über 30 Entwicklern und zur wachsenden Zahl an nicht Eclipse-basierten Projekten, insbesondere im Bereich IoT, sehen einige die Plattform als vernachlässigt an. Chris Recoskie erkennt darin die Tragik der Allmende, das Gemeineigentum, das jeder nutzt, aber um das sich keiner kümmert. Auf der Liste der wichtigsten Neuerungen folgt nach Dark Theme und Split-Editor, dass nun standardmäßig Zeilennummern bei Texteditoren eingeschaltet sind. Ohne die Java-8-Unterstützung wäre Luna für die IDE nicht viel mehr als ein Service-Update.

Die Eclipse Foundation feierte am 3. Februar ihr zehnjähriges Jubiläum. Als sie gegründet wurde, gab es 19 Projekte, 50 Mitglieder, und die Java-IDE war zweieinhalb Jahre alt. Heute sind es rund 250 Projekte, 200 Mitglieder, und die Java-IDE hat mehr als 12 Jahre auf dem Buckel.

Working Groups und Infrastrukturmaßnahmen

Strategisch setzt die Eclipse Foundation auf Working Groups, von denen es derzeit sechs gibt: Automotive, LocationTech, Long-Term Support, Internet of Things (ehemals M2M), Polarsys (Embedded Systems) und seit Juni Science (Forschungseinrichtungen). Zur Working Group Science passt die Gründung der Eclipse Foundation Europe in Form einer GmbH, um an europäische Forschungsgelder zu kommen.

Bei der Infrastruktur für die allgemeinen Projekte hat sich ebenfalls einiges getan. Die Plattform, PDE und JDK sowie die meisten anderen Projekte verwenden nun Gerrit zum Reviewen. Mit Mylyn kann man aus der IDE auf Gerrit zugreifen. Trotzdem ist es nicht ganz einfach, das richtige Gerrit-Projekt zu finden und die IDE und Git richtig zu konfigurieren. Viel einfacher ist es mit Oomph: Oomph herunterladen, ausführen und Projekt auswählen (Oomph kennt noch nicht alle, aber viele Eclipse-Projekte). Dann noch sein Eclipse- und Gerrit-Log-in sowie ein paar weitere Angaben machen, und Oomph installiert und konfiguriert Eclipse und klont das Git-Repository des zuvor ausgewählten Projekts ohne weiteres Zutun.

Wenn man eine Änderung an Gerrit sendet, startet Hudson automatisch einen Continuous-Integration-Build, um die Kompilierbarkeit zu prüfen und die (JUnit-)Tests auszuführen. Inzwischen haben die meisten Projekte ihre eigene Hudson-Instanz. Bei Eclipse heißt das HIPP (Hudson Instance Per Project). Eine Instanz zeigt nur die Jobs eines einzelnen Projekts und kann unabhängig von den anderen Instanzen um Hudson-Plug-ins erweitert werden. Ende letzten Jahres erschien Hudson 3.1. Neu sind das so genannte Team-Konzept und der um 50 bis 70 % gesenkte Speicherbedarf – ein großer Vorteil bei HIPP.

Neu, noch als beta gekennzeichnet, ist dashboard.eclipse.org, ein Dashboard von Bitergia, das irgendwann die Eclipse-Eigenentwicklung Commits Explorer ablösen soll, die unter dash.eclipse.org zu erreichen ist. Wie der Commits Explorer zeigt die Dashboard-Webseite die Anzahl der Commits pro Monat insgesamt oder nur für ein Projekt als Diagramm an, wahlweise auch aufgeschlüsselt nach Entwickler beziehungsweise Firma. Das Dashboard zeigt – was der Commits Explorer nicht konnte –, quantitativ die Aktivität des Bug-Tracking-Systems, der Mailing-Listen und die von Gerrit an.

Personell hat sich die Foundation neben dem bereits erwähnten Benjamin Cabé durch Richard Burcher als neuen Community Manager, der Wayne Beaton unterstützen wird, verstärkt. Richard (Abb. 9) ist zwar kein Eclipse-Entwickler, ist aber in der Open-Source-Szene (z. B. bei OpenStreetMap) aktiv. Bevor er zu Eclipse kam, beriet er als Selbstständiger verschiedene kanadische Regierungsbehörden beim Einsatz von Open-Source-Geoinformationssystemen.

Abb. 9: Richard Burcher

Was sich meiner Meinung nach ändern müsste

OSGi, p2, 4.x – Eclipse hat schon einige große technische Umbauten gemeistert. Nicht immer lief die Ersetzung von Komponenten ohne Reibung ab, und nicht immer war der Nutzwert klar erkennbar. Die Beliebtheit von Eclipse sank. Sollte Eclipse irgendwann auf SWT zugunsten von JavaFX verzichten, dann nur, wenn langfristig der Wartungsaufwand niedriger ist als der Aufwand für eine Kompatibilitätsschicht. Mit SWT on JavaFX gibt es bereits einen frühen Prototyp, aber den gab es auch für SWT on Swing, ohne dass dieser den Prototypenstatus verlassen hätte.

Pascal Rapicault, der maßgeblich an dem wegen seiner Komplexität auch bei einfachen Use-Cases kritisierten Update-Mechanismus und Paketmanager p2 mitwirkte, startete auf Kickstarter eine Crowd-Finanzierung für EasyEclipse for Java, einer vereinfachten Eclipse-Java-IDE. Diese scheiterte: Von den erforderlichen umgerechneten 80.000 € kamen nur etwa 5.000 € zusammen. Trotzdem bin ich der Meinung, Eclipse sollte sich nicht dem Crowdfunding verschließen. Dass es geht, zeigt die erfolgreiche Crowdfunding-Kampagne für ein Dark Theme für LiClipse, einem Eclipse-basierten Editor, und für PyDev, einer Eclipse-basierten Python-IDE. Vermutlich war diese Kampagne auch mit ein Motivationsgrund für das Dark Theme der Eclipse-Plattform. Umgerechnet 22.500 € kamen auf Indiegogo zusammen, 4.000 € mehr als notwendig gewesen wären. Als Alternative zum Crowdfunding schlug Michael Scharf ein Preisschild für Eclipse vor, wobei man unter Angabe eines Grundes auch nichts zahlen kann. Ich finde, auf der Eclipse-Webseite und im Hilfe-Menü der IDE sollte es zumindest einen Spenden-Knopf geben, um gezielt Projekte – oder besser noch Features – zu finanzieren. Außer der Option, sich selber einzuarbeiten und es selber zu machen oder einen Entwickler zu beauftragen, sollte es eine Möglichkeit geben, sich mit kleinen Beträgen – beispielsweise per flattr und mit Bitcoins wie bei Gimp – zu beteiligen. Man kann zwar bei Eclipse per PayPal/Kreditkarte spenden und wird ab $35 zum „Friend of Eclipse“, aber man kann nicht bestimmen, was mit dem Geld gemacht wird.

Abb. 10: So hat sich in zehn Jahren die Oberfläche von Firefox 1.0.7 zu 30 (oben) sowie von Eclipse 3.0 zu 4.4 (unten) geändert.

Die Oberfläche von Firefox sieht trotzt neuer Funktionen aufgeräumter aus als vor zehn Jahren. Bei Eclipse ist es genau umgekehrt: Die Symbolleiste wuchs, und es gibt mehr Views als 2004 bei Eclipse 3.0 (Abb. 10). Der heiß umkämpfte Browsermarkt zeigt, worauf es ankommt: Einfachheit und Schnelligkeit. Wenn ein langjähriger Eclipse-Nutzer frustriert zu Sublime Text, einem einfachen Editor ohne die Features einer IDE, wechselt, sollte das eine Warnung sein.

Nicht nur einfache Editoren, sondern auch Web-Anwendungen machen Eclipse-Nutzer abspenstig. Eine Brücke zwischen Desktop- und Web-IDE schlägt dagegen das neue Eclipse-Projekt Flux, das anfänglich wie das Framework von Twitter „Flight“ hieß.

Auf zum Mars!

Während das Logo und die Webseite geändert wurden, blieben Aussehen und Bedienung der Eclipse-IDE über zehn Jahre weitgehend unverändert. Der Mehrwert des diesjährigen Luna-Releases liegt vor allem in der Unterstützung von Java 8. Für die Zukunft wünsche ich mir mehr Geschwindigkeit und eine radikal einfachere Bedienung. Solange die Eclipse Foundation kein eigenes Entwicklerteam hat und Features sich nicht kaufen lassen, gibt es nur eine Möglichkeit, seine Wünsche – vielleicht schon im nächsten Simultaneous Release Mars – wahr werden zu lassen: Mitmachen! Es lebe die Meritokratie!

Aufmacherbild: The Moon covering the Sun in partial eclipse von shutterstock.com / Urheberrecht: solarseven

Geschrieben von
Holger Voormann
Holger Voormann
Holger Voormann: irgendwas mit Eclipse; früher festangestellt, seit 2010 freiberuflich; Eclipse Vex (a Visual Editor for XML) Committer, aber länger inaktiv; dafür kleinere Code-Beiträge für die Eclipse-Plattform, aber nicht als Committer; bloggt unregelmäßig (eclipsehowl.wordpress.com); antwortet nicht immer auf E-Mails (eclipse@voormann.de) und auf Tweets (@howlger)
Kommentare
  1. Andrey Loskutov2014-06-25 08:01:21

    Holger,
    FindBugs just released 3.0.0 RC build, see https://plus.google.com/113794713998126448910/posts/AXj5Bc2temn
    Korrigierst du zumindest die Online-Version von deinem Artikel?
    Danke & viele Grüße,
    Andrey

    1. dkupfer2014-06-26 10:17:00

      Wurde gestern gleich aktualisiert, auch für die Printausgabe. Danke für den Hinweis!

  2. Maarten Meijer2014-06-25 10:31:22

    Für 2004 und 2014 vergleichen Sie jetzt den Resource Perspektive mit den Java Perspective. Die waren schon immer al anders.

    1. Holger Voormann2014-06-26 17:06:21

      Bei Eclipse 3.0 war die Resource Perspective vorausgewählt. Vergleicht man Java Perspective mit Java Perspective so fällt der Unterschied nicht ganz so groß aus: 11 Icons sind es in der Symbolleiste von Eclipse 3.0, 17 dagegen bei Eclipse 4.4 (wenn jeweils kein Editor geöffnet ist).

Schreibe einen Kommentar

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