Wenn ich mir die sogenannte Top 10 Feature List so anschaue, dann haut es mich nicht aus den Socken.

Nummer 1 ist also die neue bereits vorhandene Update- und Installations-Komponente P2. Ganz ehrlich, wenn das Number 1 Feature das neue Updatesystem sein soll, das ist doch ein Scherz?

OSGi Declarative Services, Improved target platform management, Eclipse Modeling Project refinements, etc. interessieren mich eigentlich auch nicht weiter. Allerdings dann, auf Platz 6, Install into Self! Als (zukünftig bald wieder) Plugin-Entwickler ist das ein Segen, nicht jedes Mal eine neue Eclipse-Instanz starten zu müssen, sondern ein Plugin einfach in die aktuelle Umgebung zu deployen. Das ist für mich ein Killer-Feature, wird aber alle Nicht-Plugin-Entwickler kalt lassen.

Also doch kein Grund zu Klagen? Eclipse Galileo scheint für diverse Anwendungsbereiche neue und interessante Features zu beinhalten, und dieses breite Spektrum zeigt doch auch sehr schön, wie weit und breit Eclipse inzwischen verbreitet ist und was für ein Erfolg es als Plattform hat.

CDT

Auch das CDT hat natürlich einige Neuerungen erfahren, allerdings muss man sich bewusst sein, dass die Version von 5 nach 6 nicht etwa wegen der vielen neuen Features geändert wurde, sondern wegen inkompatibler APIs. Nichtsdestotrotz, Neues hat Einzug gehalten.

Nett ist sicherlich, dass nun auch Operatoren wie andere Funktionen behandelt werden was den Indexer anbelangt. Konkret bedeutet das, dass ein Go To Declaration auf einem Operatoren mich zu seiner Deklaration führt. Das ist sogar relativ oft nützlich, denn die Streaming-Operatoren sind häufig überladen.

Von der Refactoring-Front gibt es (leider) nicht sehr viel zu berichten. Ein Extract Local Variable wurde eingeführt, und es scheint in vielen Situationen zu funktionieren, wie meine Tests bisher ergeben haben. Aus besonders geheimen Quellen weiss ich, dass ein Change Method Signature Refactoring in Arbeit ist, wenn alles klappt werden wir das im nächsten Jahr zu sehen bekommen, wenn es heisst, Helios!

We [the Eclipse Foundation, or parts of it, not sure] have a serious IP concern with DVCS’s in general. There have been several times in the past where our IP team has uncovered code in our repositories which had to be deleted. [..] How do you really really delete code across all instances in a DVCS?

Tja, unerwartet, aber doch irgendwie einleuchtend. Wir sehen, auch auf den ersten Blick unsinnige Anforderungen können eine Berechtigung haben. Was lernen wir daraus? Wir Software-Entwickler haben einen harten Job

(Ach ja, und natürlich geht das mit Git sehr wohl, allerdings ist es doch relativ hässlich. Naja, sollte es vielleicht auch sein.)

Super, was? So, und nun “spread the word on what can be done and how”, wie Doug auf der letzten Folie aufruft.

Ich werde mich auf das JDT, also die Java Development Tools, PDE, sowie die Plattform beschränken; Emanuel wird dann hoffentlich über die Neuigkeiten im CDT berichten.

Extract Class Refactoring

Starten wir mit meinem Lieblingsthema: Refactoring. Und zwar gibt es ein neues Refactoring, welches einem einfach erlaubt, Teile einer bestehenden Klasse in eine Neue auszulagern:

Das Resultat ist eine Klasse mit den selektierten Feldern, sowie delegierenden Methoden aus der Ursprungsklasse.

Rearrange Content of Files Per Drag&Drop

Auch ganz nett ist, dass man Member innerhalb einer Klasse per Drag&Drop verschieben kann:

(Den Cursor muss man sich vorstellen, er zieht das selektierte Element an die Position der schwarzen Linie.)

Rename Field Renames Properties key

Auch eine sehr nützliche Erweiterung ist beim Rename Field Refactoring hinzugekommen: Beim Umbenennen eines Feldes, welches als Message-String verwendet wird, wird auch automatisch der entsprechende Key im messages.properties-File umbenannt. So kleine Dinge sind es nämlich, welche einem das Arbeiten mit Eclipse so angenehm machen.

New Quick Assist: MessageFormat

Mit + zusammengesetzte Strings sind zum einen häufig nicht sehr leserlich und zum anderen nur sehr mühsam zu internationalisieren. Abhilfe schafft ein neuer Quick-Fix:

Read and Write Occurrences

Mark Occurences ist schon mindestens seit der vorlezten Version dabei, aber natürlich kann man auch dieses Feature noch verbessern, und zwar durch eine farbliche Unterscheidung von Lese- und Schreibzugriffen (das doofe Beispiel sei mir vergeben).

JUnit View Shows Execution Time

Hm ja, der Titel sagts wohl schon:

Plug-in Spy

Endlich! Der Plug-in Spy ist Teil des PDE. Der Plug-in Spy ist sehr nützlich, wenn man sich beispielsweise fragt, welche Klasse die aktuelle View implementiert oder auch, wie der Identifier für die View lautet. Das hätte mir zu Beginn meiner Plug-in Entwickler-Karriere einiges an Zeit gespart.

Das waren wohl die für mich wichtigsten Neuerungen. Ich bin mir sicher, dass ich im Lauf des Jahres noch einige andere coole Dinge entdecken werde.

Viel Spass! Und wer immer noch nicht genug hat, findet in den New and Noteworthy Seiten noch ganz vieles mehr.

In a nutshell, OSGi is a module system for Java, but what does that
really mean?

Etwas mehr und ausführlicher in Neil’s Blog.

Und wer dann immer noch nicht genug hat, sollte sich das SE-Radio Interview mit Peter Kriens and BJ Hargrave zum Thema OSGi anhören.

Zudem haben die Committer-Abstimmungen für Emanuel Graf heute begonnen, 5 Stimmen hat er schon — ich denke man darf bereits gratulieren

So, und wer jetzt glaubt reklamieren zu müssen, ja, Implement Method und Generate Getters and Setters sind keine Refactorings, aber es lohnt sich (noch) nicht, für zwei Einträge ein Top-Level Source-Menu einzuführen.

Der Gesamtumfang der Patches beträgt knapp 24000 Zeilen, wobei schlussendlich nur ein einziges Refactoring (Extract Constant) inbegriffen ist, der Rest dient als Basis für weitere Refactorings, welche in nächster Zeit folgen werden, und umfasst Dinge wie Source-Transformationen, Code re-writing, Kommentarbehandlung, und natürlich ganz viele Tests. Wir hoffen, damit (endlich) den Sprung zu schaffen und ein offizieller Teil des CDT zu werden. Langfristiges Ziel ist natürlich, selbst Committer zu werden, allerdings ist das nicht so einfach wie man meinen könnte (in dieser Hinsicht unterscheidet sich Eclipse von den meisten anderen Open-Source Projekten die ich kenne). Jetzt können wir nur noch hoffen, dass wir möglichst rasch durch das IP-Review kommen und unser Code schnell im CVS landet (das Arbeiten mit gepatchten Quellen auf die man nicht committen kann ist nicht besonders spassig :/ ).

Wer das ganze genauer mitverfolgen will, sollte sich bei den beiden relevanten Bug-Reports anhängen, oder gleich bei unserem Trac.

Was durch folgenden Code ersetzt wird:

Ok, was fällt auf? StringBuffer! Dabei sollte man grundsätzlich immer StringBuilder verwenden, welcher im Gegensatz zum StringBuffer nicht synchronisiert ist. Um Thomas, unseren Parall- und Netzwerkprogrammierexperten, zu zitieren, ist der StringBuffer “unglaublich schweinisch sauteuer”.

Nehmen wir an, es würde anstelle des Buffers ein Builder verwendet, dann wäre der QuickFix trotzdem ziemlich unsinnig, denn der Compiler (zumindest Sun’s) ersetzt manuelle String-Konkatenationen sowieso durch StringBuilder-Aufrufe. Aus:
int offset = 3, line = 5;
String s = "Offset " + offset + " is at line " + line;entsteht also folgender ByteCode:

0  iconst_3
1  istore_1 [offset]
2  iconst_5
3  istore_2 [line]
4  new java.lang.StringBuilder [16]
7  dup
8  ldc  [18]
10  invokespecial java.lang.StringBuilder(java.lang.String) [20]
13  iload_1 [offset]
14  invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
17  ldc  [27]
19  invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [29]
22  iload_2 [line]
23  invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
26  invokevirtual java.lang.StringBuilder.toString() : java.lang.String [32]
29  astore_3 [s]
30  return

Interessanterweise wurde der QuickFix auch schon an anderer Stelle kritisiert, allerdings nicht das Kernproblem:

I know using StringBuffers is better for performance.

Tsts…

Ich überlege mir, einen Patch einzureichen, der den QuickFix wieder löscht

Die Gefahr ist halt gross, dass man einfach mal etwas “drauf los programmiert” und danach das Gehirn einschaltet und die rot unterkringelten Statements noch mal genauer anschaut. Das ist vielleicht auch ein Grund dafür, dass, um den neumodischen Begriff zu verwenden, “dynamische Programmiersprachen” von vielen verschmäht werden, da man nicht die (trügerische) “Sicherheit” einer IDE hat.

Um wieder zurück zur Schule zu kommen: Sich auf die IDE zu verlassen ist auch in Hinsicht auf die bevorstehenden Prüfungen vielleicht nicht die beste Idee.