Eclipse Galileo, Yeah! Oder?

Man liest es überall, eine neue Eclipse Version wurde vor kurzem veröffentlicht! Die letzten Jahre immer ein Grund zur Freude, endlich kann man die diversen RCs wegschmeissen und Final installieren. Nur dieses Jahr hat mich das ganze eher kalt gelassen. Nicht weil ich Eclipse nicht benutze, als CDT-User (und ehemaliger Contributor) läuft es jeden Arbeitstag. Ist Eclipse Galileo also kein Grund zur Freude?

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!

2 comments »

Unerwartete Anforderungen an Software

Ueber ein interessantes Beispiel an eine ziemlich unerwartete Anforderungen an eine Software bin ich heute gestolpert. Aber zuerst eine Frage: Soll ein SCM / VCS (wie auch immer) es erlauben, Code zu löschen? Und zwar auch aus der History, nicht ab einer bestimmten Revision. Ich denke, dafür ein einstimmiges «Nein» zu erhalten. «Blödsinn, muss man nicht können, ja soll man nicht mal können». Tja, anscheinend besteht dafür doch Bedarf, wie ich eben in diesem Eclipse Bug-Report gesehen habe:

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.)

3 comments »

Code Analysis and Refactoring with CDT

Doug Schäfers Slides vom Eclipse Summit Europe sind nun online verfügbar. Für uns Insider natürlich nicht viel neues, aber es ist doch schön, wenn jemand unsere Arbeit präsentiert. Irgendwie cool :-) Ausserdem hats sogar Code von mir in der Präsentation:

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

3 comments »

Neues im Ganymede CDT

Gibts bei Emanuel.

No comment »

Neues in Eclipse 3.4 Ganymede

Es ist wieder mal so weit, Ende Juni wird die neuste und schönste Version von Eclipse im Zug des Ganymede Release-Trains veröffentlicht. Wie auch schon letztes Jahr möchte ich hier gerne einige der Neuerungen vorstellen.

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.

Ganymede is coming!

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

2 comments »

Was ist eigentlich OSGi?

Alle die schon mal mit Eclipse gearbeitet haben sind schon in den Kontakt mit OSGi gekommen, vielleicht ohne das zu Wissen. Auch alle, die Eclipse Plug-ins schreiben haben definitiv auch mit OSGi gearbeitet. Was OSGi genau ist erklärt Neil Bartlett in seinem Blog sehr schön:

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.

No comment »

CDT C++ Refactorings in Ganymede!

Jawohl, es ist soweit, heute wurde unser letzter grosser Patch angenommen. Folgendes Menu wird also jedermann Ende Juni im neusten CDT-Release vorfinden:

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.

6 comments »

CDT C++ Refactoring Plug-In in Ganymede?

Am letzten Mittwoch haben wir einen grossen Schritt getan und die notwendigen Patches für den C++ Refactoring-Support für CDT fertiggestellt.

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.

5 comments »

Verwirrung um StringBuilder und StringBuffer bei Eclipse

Im News and Noteworthy des Eclipse 3.4M4 habe ich heute morgen etwas ziemlich komisches gesehen, und zwar gibts es einen neuen Quickfix:

convert-to-sb.png

Was durch folgenden Code ersetzt wird:

convert-to-sb2.png

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 ;-)

5 comments »

IDE-Verbot für Anfänger?

Ich überlege mir gerade ernsthaft, ob es nicht sinnvoll wäre, den Erstsemestrigen, also den Programmieren 1 Besuchern, den Einsatz einer IDE zu verbieten. “Du Unmensch”, höre ich euch schon rufen, “es ist doch Java!”. Ich weiss, aber was soll ich sagen, wenn Studenten (so wie ich das heute in der Pause mitanhören musste) keine Ahnung von Packages haben, aber sich darauf verlassen, dass Eclipse ein rotes Kreuzchen macht, das man nur anklicken muss und alles korrigiert wird. Ähnliche Probleme gibt es beim Unterschied zwischen Instanz- und Klassenmethoden, sowie deren Sichtbarkeit.

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.

7 comments »