IDEDeluxe

Codeo

2010-11-17T07:23:00.000+01:00

Die Lage beginnt sich zu normalisieren. Aber da abzusehen ist das mir für private Programmierprojekte in absehbarer Zukunft keine Zeit bleibt wird sich dieser Blog ein wenig verändern. Er wird wohl alles wiederspiegeln was mich auf der Arbeit beschäftigt.

Bis vor etwa einem Jahr war ich leitender Entwickler für die ActionScript-IDE FDT. Im Programmieralltag stand das Parsen des Sourcecodes und das Aufbauen von Funktionalitäten auf dem resultierenden AST/Model im Vordergrund. Hier hatte ich viel Spaß.

Nun habe ich Wohnort und Arbeitsplatz gewechselt und arbeite wieder an einem großen Eclipseprojekt. Diesmal handelt es sich um CODEO, eine IDE auf Eclipsebasis zum Entwickeln von Software für eingebette Systeme. Ich bin gespannt welche Erfahrungen von FDT ich hier einbringen können werde, wo Überschneidungen zu sehen sind und wo sie sich grundlegend Unterscheiden.

Private Projekte

2010-06-12T09:03:00.001+02:00

ByteCodeDeluxe ist leider erst mal auf Eis gelegt. Sehr schade, habe viel Spaß damit gehabt. Doch momentan habe ich zwei Projekte die alle Freizeit voll in Anspruch nehmen. Mal schaun wies in einigen Monaten aussieht ...

Drei Plugins - Annotation Processor

2010-01-05T06:58:00.000+01:00

Ein schönes neues Jahr! Es ist die Zeit wieder an die Arbeit zu gehen ... und die Zeit für ein kleines Update über den Entwicklungsstand der drei Plugins.

Die Entwicklung des Parsers unter Nutzung der Reflection API ist relativ weit gut gegangen. Leider bin ich an eine Stelle gekommen an der ich keine andere Möglichkeit sah als die Struktur des Bytecodes doch noch ein zweites mal zu codifizieren ... und genau das wollte ich ja vermeiden. Der Wunsch nach Codegenerierung aus den Annotations wurde laut. Und genau das leisten Java Annotation Processors.
Ein Annotation Processor wird in den Compiliervorgang eingeklinkt und erweitert quasi den Compiler. Er kann Errors, Warnings und Code generieren. Das kann sowohl Sourcecode sein, der dann in einer weiteren Runde kompiliert wird, oder direkt Bytecode. Alle drei IDEs unterstützen Annotation Processoren, so dass die Portierbarkeit des Codes nicht eingeschränkt wird.

Natürlich wird die Umstellung die Entwicklungszeit verlängern. Lohnt sich dieser Aufwand? Da der Lernprozess für mich an dieser Arbeit mindestens ebenso wichtig ist wie das Ergebnis ist die Antwort "Ja". Hier folge ich dem Motto: "Sei Konservativ auf der Arbeit und tue was du bereits kannst, in der Freizeit ist Platz für Experimente!".

Ein Problem welches sich mir bei der Arbeit mit Annotation Processoren stellt ist die Testbarkeit derselben. End-To-End-Tests sind leicht zu realisieren, allerdings dauert der programmatische Aufruf des Compilers auf meinem, relativ aktuellen, System bereits eine halbe Sekunde. Das schränkt die Nutzbarkeit als TDD-Tests ein wenig ein. Und die API zu mocken ist relativ schwierig (kurze Diskussion: http://stackoverflow.com/questions/1811967/how-to-write-automated-unit-tests-for-java-annotation-processor). Sobald ich Sicherheit gewonnen habe wie ich hier vorgehe werde ich darüber berichten. Für einen kurzen Eindruck ... so sieht momentan mein Code aus für einen End-To-End-Test, der verifiziert das ein Error-Marker an einer bestimmten Stelle im Code erzeugt wurde.

@Test
public void missingStructureAnnotationOnMainClass() throws Exception {
    SourceBuilder file = new SourceBuilder();
    file.line("import com.idedeluxe.binary.*;");
    file.line("@Binary ???class Foo {}");
    assertMarkersAreGenerated(file);
}

Hier wird sicher gestellt, dass ein Error Marker für die Klasse "Foo" erstellt wird. Intern wird dafür die Eingabe Analysiert, die Position(en) von "???" gespeichert und aus der Eingabe entfernt, der Compiler wird zusammen mit dem Annotation Processor auf die Eingabe angesetzt und es wird verifiziert, dass die Marker an der angegeben Stellen erzeugt werden (und keine Überflüssigen Marker erzeugt werden).

Rewrite or Refactor?

2009-11-21T09:17:00.001+01:00

Das Team arbeitet seid einigen Jahren an dem Produkt. Es ist erfolgreich und verdient gutes Geld. Die Kunden sind glücklich (auch wenn sie sich beschweren, im großen und ganzen sind sie glücklich). Aber hinter den Kulissen brodelt es. Die Entwickler haben keinen Spaß mehr an der Arbeit. Jedes neue Feature braucht länger als das vorhergehende. Das Management muss immer wieder katastrophal hohe Zeitschätzungen entgegennehmen die sich mit keinem Marketingplan vertragen. Die Entwickler werden gedrängt zu sparen und "schneller zu entwickeln, wir haben keine Wahl!". Und irgendwann ist es so weit: die Entwickler nehmen all ihren Mut zusammen und sprechen mit dem Chef.

Entwickler: "Wir können so nicht mehr arbeiten. Das alte System ist verrottet. Natürlich können wir weiter Features einbauen, aber wegen dem schlechten Code wird das immer langsamer werden. Und langsamer. Und langsamer. Das wird richtig teuer und immer teurer! Wir haben nur eine Möglichkeit ... wir müssen das System neu schreiben!".

Chef: "Aber wird das neu schreiben nicht auch teuer? Wird es nicht sehr lange dauern?"

Entwickler: "Natürlich wird es einige Zeit beanspruchen. Aber wir sind auch in einer sehr starken Position. Wir haben all das schon mal gemacht. Wir wissen jetzt genau was das System können muss und können von Anfang an die Anforderungen haargenau definieren. Wir werden viel schneller sein als beim ersten mal denn wir können die Architektur diesmal genau an die Anforderungen anpassen. Wir setzen uns hin, analysieren den alten Code und schreiben die Anforderungsliste haarklein nieder. Dann entwickeln wir die passende Architektur. Und zum Schluss brauchen wir bloß noch alles runter zuschreiben."

Chef: "Na gut, wie lange schätzt ihr denn dass ihr brauchen werdet?"

Entwickler: "Eine exakte Schätzung ist zwar sehr schwierig, aber wir haben uns natürlich schon Gedanken gemacht. Wir denken, dass wir das in drei bis sechs Monaten geschafft haben. Das mag zwar viel klingen, aber die Zeit haben wir schnell wieder raus. Schließlich arbeiten wir dann auf einer sauberen Architektur und können neue Features viel schneller entwickeln."

Nach einigem hin und her sind sich alle einig. Die beste Lösung ist es tatsächlich das System neu zu schreiben und dann auf dem neuen, sauberen, komplett getestetem Code effizient neue Features zu implementieren.

Wird das Erfolg haben?

Konsequenzen

Die Welt steht nicht still. Die Annahme, dass man alle Anforderungen durch eine Analyse der vorhandenen Anwendung gewinnen kann ist naiv. Die Software wird von Kunden verwendet, in einer sich schnell ändernden Welt. Das Management kommt nicht ohne Grund häufig zu den Entwicklern und verlangt "dieses Feature so schnell wie möglich". Den letzten beißen die Hunde und die Konkurrenz schläft nicht. Ein Feature das heute das Geld in die Taschen spült ist in drei Monaten keinen Pfifferling mehr wert. Wenn ein halbes Jahr eingeplant wird um Funktionalität neu zu implementieren die schon vorhanden ist (wenn auch häßlich, schlecht wartbar, nicht erweiterbar ...) dann kommen zwangsläufig während dieser Zeit neue Anforderungen. Und diese können nicht einfach ignoriert werden. Die Kunden erwarten Fortschritt, die Software muss verkauft werden weil jede nicht verkaufte Lizenz bares Geld kostet.

Weil sich die Anforderungen also auch während der Neuentwicklung ändern gibt es zu Anfang der Neuentwicklung keine Chance eine vollständige Anforderungsliste zu erstellen. Genauso wie immer werden sich die Anforderungen während der Entwicklung ändern. Und die Architektur wird unvollkommen sein. Während der Neuentwicklung werden unvorhergesehene Anpassungen vornehmen müssen, was den Gesamtaufwand vergrößert. Die Entwicklung wird länger dauern als geplant war, es werden noch mehr neue Anforderungen kommen und der Druck wird steigen.

Der Druck wird so weit steigen, dass das Management die Entwickler bittet das neue Feature "so schnell wie irgend möglich" einzubauen. Wieder werden Kompromisse gemacht werden. Das Ende vom Lied ist, dass die Anwendung trotz allem guten Willens nach einigen Jahren genauso verrottet ist wie die Alte. Und der Wunsch alles neu zu machen, alles "auf saubere Füße zu stellen", kommt auf. Es ist nichts gewonnen, nur eine Menge Zeit verloren.

Aber was ist die Alternative?

Ursachen

Um die Alternative zu finden muss zuerst das eigentliche Problem erkannt werden. Der alte, verrottete, nicht erweiterbare Code ist nicht schuld. Code kann keine Schuld tragen, es ist nur ein Text. Und dieser ist nur ein Ding, nichts dem man eine Schuld für irgend etwas geben könnte.

Das Management ist auch nicht Schuld. Die Prioritäten des Managements müssen "so viele Features so schnell wie möglich" sein, denn das ist es was die Kunden wollen. Und man kann nicht erwarten das jede Person in der Hierarchie die Probleme der Entwickler versteht, das verstanden wird was es bedeutet wenn der Code verrottet und welche Entscheidungen dazu führen, dass dies geschieht.

Die letztliche Verantwortung über die Qualität der Software kann nur bei den Entwicklern liegen. Nur hier sind alle Informationen und alles Wissen (hoffentlich) verfügbar um die täglichen Entscheidungen zu treffen. Um zu entscheiden: Wird dieses Feature jetzt ganz dreckig rein gehackt, oder müssen wir uns ein klein wenig Zeit nehmen? Ist ist nicht praktikabel jedes mal den Chef zu befragen ob das jetzt so oder so implementiert werden soll. So schwer das ist, diese Verantwortung kann nicht in der Hierarchie weiter nach oben gereicht werden. Die Entwickler müssen an dieser Stelle die Verantwortung akzeptieren und verantwortungsvoll handeln.

Was aber heißt verantwortungsvoll? Es ist verlockend den Leuten "über einem" die Verantwortung zu geben. Auf ein "Wir brauchen dieses Feature so schnell wie möglich" mit einem "Na gut, dann scheiß ich das hier in den Code rein. Ich sag euch das wird nicht lecker, aber ihr habt es so gewollt!" zu reagieren. Der Chef wird ein Lob aussprechen, weil der Entwickler so gute Arbeit macht, die Kollegen werden ihn bewundern, weil dieses harte Feature so schnell erledigt wurde, der Entwickler wird gut dastehen.

Aber er hat nicht verantwortungsvoll gehandelt. Denn die Kosten sind nicht gesunken. Sie sind gestiegen! Code wird einmal geschrieben, aber oft gelesen. Die Kosten um neue Features zu implementieren sind durch die Entscheidung ein klein wenig angestiegen, denn es ist schwieriger neue Features auf Dreck aufzubauen als auf Code der einen Unterstützt. Wenn der Code an einer oder zwei Stellen dreckig ist, weil ein Feature tatsächlich lebensnotwendig für die Firma war, dann kann man damit Leben. Wenn das Dreckige aber zur Gewohnheit wird, dann wird die Entwicklung immer langsamer und langsamer, bis es unmöglich erscheint in dem alten Kram weiter zu arbeiten.

Man kann sich hier der Metapher des Schulden machens bedienen ... ein schnell gehacktes Feature ist wie ein Kauf auf Pump. Man kann damit glänzen, man erhält schnell ein neues Feature, und wenn man es nicht übertreibt ist es auch ok. Aber die Zinslast ist in Form gesunkener Produktivität in der Zukunft zu zahlen, und wenn die Schulden zu hoch werden muss Insolvenz angemeldet werden ... ein Rewrite steht bevor.

Was also kann getan werden?

Alternative

Jeder Entwickler muss für sich seinen Teil der Verantwortung übernehmen. Natürlich kann man immer sagen "Ich habe keine Schuld, der Entwickler vor mir hat nur Müll zurück gelassen!". Aber man muss sich, wenn man längere Zeit an einer vorhandenen Codebasis gearbeitet hat, auch fragen lassen ob es denn besser geworden ist seid man dabei ist. Hat man einfach weiter gemacht wie bisher, oder hat die eigene Arbeit zu Verbesserungen geführt? Ist die Schuldenlast gesunken?

Der komplette Rewrite einer Software ist im Prinzip nichts anderes, als alle Schulden die man im Laufe der Jahre angehäuft hat mit einem Schlag zurück zu zahlen. Oder besser noch: abzuarbeiten. Aber das ist in der Regel ein zu großer Batzen, denn so lange man nur Schulden abarbeitet hat man kein Geld für den Lebensunterhalt. Daher muss eine Strategie der kleinen Schritte gefunden werden. Die Schuld muss Stück für Stück getilgt werden, damit man nebenher noch für seinen Lebensunterhalt arbeiten kann.

Der erste Schritt auf diesem Weg besteht darin keine weiteren Schulden mehr aufzunehmen. Wenn die Entwickler weitermachen wie bisher, also der neue Code nicht besser ist als der Alte, dann wird sich nichts ändern. Neuer Code muss "high quality" sein! Das ist zunächst einmal ungewohnt, weil man zuerst einmal langsamer wird, aber es ist unumgänglich wenn man aus der Falle ausbrechen will.

Der zweite Schritt ist es die Schulden Stück für Stück zurück zu zahlen. Der ganzen Batzen ist zu groß. Aber als Entwickler kann ich mich jedes mal, wenn ich an einer vorhandenen Codestelle arbeiten muss, fragen "Ist das guter Code? Kann ich ihn verbessern? Einfacher machen? Ist es duplizierter Code? Kann ich abstrahieren?". Und ähnliche Fragen. Dabei muss nach meiner Arbeit nicht alles Gold sein. Es muss nur ein wenig besser sein als vorher. Wenn alle Entwickler jedes mal wenn sie arbeiten dafür sorgen, dass der Code ein wenig besser wird, ein wenig der Schuld zurück gezahlt wird, ein klein wenig refactoring betreiben, dann wird die Entwicklung langfristig wieder schneller werden. Das wird nicht innerhalb einiger Wochen geschehen, dafür ist der Code vermutlich schon zu verrottet, aber die kontinuierliche Pflege wird den Patienten wieder auf die Beine bringen.

Das also ist der Weg:

Verantwortung übernehmen
Neuer Code muss guter Code sein
Den alten Code jeden Tag ein wenig verbessern

Martin C. Fowler über "The big redesign in the sky"
Chad Fowler über "The big rewrite"

Drei Plugins - Model

2009-11-03T21:56:00.002+01:00

Modelstrukturen

Vom Beginn an war ein Ziel in ByteCodeDeluxe, die Struktur des Bytecodes deklarativ auszudrücken. Services, wie zum Beispiel ein Bytecode Parser, arbeiten auf dieser Struktur um ihre Arbeit zu verrichten. Auf diese Weise wird vermieden, dass die Struktur des Bytecodes an verschiedenen Stellen dupliziert wird (zum Beispiel einmal für die Lese- und einmal für die Schreibroutine).

External DSL

Dabei wurden verschiedene Ansätze durchdacht. Eine Möglichkeit wäre eine externe DSL gewesen. Die Aufgabe an sich ist schon reizvoll. Ich habe in der Vergangenheit mit ANTLR und JavaCC gearbeitet und man landet schnell bei dem Gedanken ein vergleichbares Tool für Binärdateien zu implementieren. Dies aber ist definitiv "out of scope" und würde das angestrebte Ergebnis, einen Java-ByteCodeEditor, deutlich hinauszögern. Schnell würde die Bibliothek zum Hauptaugenmerk der Implementierungsarbeit werden und Wünsche nach einem Editor und anderem Toolsupport würden laut. Deswegen wurde dieser Ansatz verworfen.

JDT - PropertyDescriptor

Die Idee zur letztlich verwendete Implementierung stammt aus dem JDT. Eine Sourcedatei wird hier durch einen AST (im Package "org.eclipse.jdt.core.dom") beschrieben. Die Elemente diesen ASTs, zum Beispiel "MethodDeclaration", "NumberLiteral", "WhileStatement", tragen jeweils wiederum einen sogenannten "PropertyDescriptor". Diese Descriptoren beschreiben den grundsätzlichen Aufbau der Elemente. Das sieht dann im Code, hier für ein WhileStatement, so aus:

/** while( Expression ) Statement */
public class WhileStatement extends Statement {
  public static final ChildPropertyDescriptor EXPRESSION_PROPERTY =
    new ChildPropertyDescriptor(WhileStatement.class, "expression",
      Expression.class, MANDATORY, CYCLE_RISK);

  public static final ChildPropertyDescriptor BODY_PROPERTY =
    new ChildPropertyDescriptor(WhileStatement.class, "body",
      Statement.class, MANDATORY, CYCLE_RISK);

  private static final List PROPERTY_DESCRIPTORS;

  static {
    List propertyList = new ArrayList(3);
    createPropertyList(WhileStatement.class, propertyList);
    addProperty(EXPRESSION_PROPERTY, propertyList);
    addProperty(BODY_PROPERTY, propertyList);
    PROPERTY_DESCRIPTORS = reapPropertyList(propertyList);
  }

Jedes Element des DOMs ist also in der Lage über seine statische Struktur Auskunft zu geben (es hat einen Namen, weiß ob es optional ist usw.). Es gibt Methoden wie "getStructuralProperty", welcher man einen Descriptor gibt und man bekommt das echte AST-Element, welches mit dieser Struktur im fraglichen Node verknüpft ist. Letztlich also eine Metabeschreibung des ASTs. Nun kann man Logik auf dieser Metabeschreibung implementieren anstatt sie direkt auf dem AST zu implementieren, die AST-Struktur leakt also nicht nach draußen.

ByteCodeDeluxe 0.1 - Structure

In ByteCodeDeluxe sind die PropertyDescriptoren ersetzt worden durch die Model-"Structure". Genau wie ein PropertyDescriptor im JDT beschreibt eine Structure einen Elementtyp des Baumes. Mit Hilfe dieser Metaebene der Beschreibung läßt sich die Struktur des Bytecodes relativ kompakt darstellen. Um zum Beispiel die Struktur einer "Method-Info" (hier der Weg zur Spec) abzubilden bedarf es folgenden Codes:

/** method_info {
 *   u2 access_flags;
 *   u2 name_index;
 *   u2 descriptor_index;
 *   u2 attributes_count;
 *   attribute_info attributes[attributes_count];
 *  } */
public class MethodInfo extends AbstractNode {

  public static final FlagStructure ACCESS_FLAGS =
    new FlagStructure("access_flags", 2, MethodFlags.values());
  public static final ArrayIndexStructure NAME_INDEX =
    new ArrayIndexStructure("name_index", 2, ClassFile.CONSTANT_POOL);
  public static final ArrayIndexStructure DESCRIPTOR_INDEX =
    new ArrayIndexStructure("descriptor_index", 2, ClassFile.CONSTANT_POOL);
  public static final ArrayLengthStructure ATTRIBUTES_COUNT =
    new ArrayLengthStructure("attributes_count", 2);
  public static final ArrayStructure ATTRIBUTES =
    new ArrayElementCountingStructure("attributes",
      new StringSelectionStructure("attribute", 2,
        ClassFile.CONSTANT_POOL, AttributeInfo.ATTRIBUTES_MAP),
      ATTRIBUTES_COUNT, false);
  public static final Structure[] STRUCTURE =
    new Structure[] { ACCESS_FLAGS, NAME_INDEX, DESCRIPTOR_INDEX,
      ATTRIBUTES_COUNT, ATTRIBUTES };

  public Structure[] getStructure() {
    return STRUCTURE;
  }

  public String getName() {
    return ((ArrayIndex) getChild(NAME_INDEX)).getTarget().
      getValueString();
  }
}

Mit diesem Werkzeugkoffer ist die Spec relativ schnell runter geschrieben. Ein Parser traversiert dann nur noch die (statische) Struktur und instantiiert Nodes die dann als Model dienen und die Daten speichern. Dadurch haben die Nodes allerdings eine Doppelfunktion ... einerseits sind sie die Strukturbeschreibung des Bytecodes, andererseits dienen sie als Modelelemente und halten die eingelesenen Daten. Durch diese Doppelfunktion neigen sie dazu Funktionalität anzuziehen und damit zu Hybriden zu werden (nicht ganz Klasse nicht ganz Datenstruktur ... an dieser Stelle möchte ich einmal einen Hinweis auf das wundervolle Buch "Clean Code" geben). Auch wird man den Gedanken nicht los, ob es nicht doch noch ein wenig kompakter geht.

ByteCodeDeluxe 0.2 - Structure

In der Version 0.2 sollen die großen zwei Schwächen der alten Struktur, Doppelfunktion der Strukturnodes und suboptimale Lesbarkeit der Bytecodebeschreibung, ausgemerzt werden. Die Beschreibung soll nicht mehr als Datencontainer dienen und deutlich verkürzt werden.

Die Idee ist, die Struktur mit Hilfe von Java-Klassen zu beschreiben und reflektiv auszulesen, also den Javasource quasi direkt als deklarative Beschreibungssprache zu nutzen. Annotations können verwendet werden um das Modell mit zusätzlichen Informationen anzureichern. Services können dann auf dieser Struktur arbeiten.

Dieses Vorgehen bringt offensichtlich einen Performanceoverhead mit sich. Aber: auch der alte Ansatz ist mit Sicherheit nicht besonders performant, für die Modelle werden sehr viele Objekte instantiiert. Außerdem ist die Performance in diesem Kontext von untergeordneter Bedeutung. Für den Editor werden immer nur einige wenige class-Dateien geöffnet und wenn das eine hundertstel Sekunde (oder auch eine zehntel Sekunde) dauert ist das nicht weiter schlimm.

Wie könnte eine solche Annotation nun konkret aussehen? Ich bin noch dabei an den Details zu arbeiten, aber ich stelle mir in etwa folgendes vor:

/** method_info {
 *   u2 access_flags;
 *   u2 name_index;
 *   u2 descriptor_index;
 *   u2 attributes_count;
 *   attribute_info attributes[attributes_count];
 *  } */
@Structure( { "accessFlags", "nameIndex", "descriptorIndex",
              "attributesCount", "attributes" })
public class MethodInfo {
  @Flags(MethodAccessFlags.class)
  U2 accessFlags;
  @ConstantPoolIndex(ConstantUtf8Info.class)
  U2 nameIndex;
  @ConstantPoolIndex(ConstantUtf8Info.class)
  U2 descriptorIndex;
  @TableSize(tableName = "attributes")
  U2 attributesCount;
  AttributeInfo[] attributes;
}

Die Informationsmenge ist in etwa so hoch wie im Beispiel von Version 0.1, allerdings deutlich kompakter geschrieben. Ein Parser würde nun reflektiv die Klassenstruktur mit den Annotations lesen und benutzen um den Input zu parsen und die Modelelemente zu instantiieren.

Mit Hilfe dieser Struktur ist der Code nun beinahe so kompakt als wäre es eine DSL. Nur muss weder ein Parser geschrieben werden, noch ein eigenes Toolset entwickelt werden ... die Java-Reflection-API und jede beliebige Java-IDE reicht als Toolset und die Beschreibung des Bytecodes ist rein deklarativ!

Drei Plugins - Eröffnung

2009-10-22T20:01:00.005+02:00

Präludium

Vor kurzem wurde bekannt gegeben, dass der Source Code von IntelliJ IDEA veröffentlicht wird. Mich persönlich begeistert diese Nachricht, auch wenn ich bisher noch nicht mit IDEA gearbeitet habe. Bisher habe ich für meine tägliche Arbeit ausschließlich Eclipse verwendet (wenn man mal von der "guten alten Zeit" absieht, als der Texteditor noch das Mittel der Wahl war). Natürlich wurde bereits in IDEA gestöbert, genauso wie in Netbeans, aber um diese Tools wirklich kennen zu lernen braucht es ein Projekt.

Nun sind die drei großen Java-IDEs Open Source. Das beflügelt die Fantasie. Die Eclipse-API ist mir in den letzten Jahren in Fleisch und Blut übergegangen. Und auch wenn es immer wieder Ecken gibt die ich noch nicht besucht habe, all zu viel Neues/Überraschendes/Reizvolles gibt es nicht mehr zu entdecken (zumindest nicht bis e4 sich der Fertigstellung nähert). Aber was ist mit den beiden anderen Playern? Jede IDE hat ihre Fangemeinde, jede hat ihre Stärken und Schwächen, jede ist auf ihre Art und Weise Reizvoll.

Ich brauche ein Projekt das es mir erlaubt mich in die IDEs einzuarbeiten, nicht nur Oberflächlich sondern bis ins Detail, bis in die API, so weit wie möglich. Und was wäre da besser geeignet als ein Plugin, welches für alle drei IDEs funktioniert? Ein solches Programm wird es mir ermöglichen mich sowohl in die Benutzung als auch in die API einzuarbeiten. Und weil ich denke das diese Gedanken/Erfahrungen/Erkenntnisse auch für andere interessant sein werden, werde ich sie teilen.

Die Idee

ByteCodeDeluxe ist Anfang des Jahres in der Version 0.1 veröffentlicht worden und ich bin recht zufrieden damit. Die Entwicklung hat Spaß gemacht, wie bei jedem Hobby-Projekt lag der Fokus auf der Lernerfahrung. In diesem Fall habe ich angefangen den Java-Bytecode kennen zu lernen. Die Architektur ist gut, die Umsetzung allerdings noch nicht zu hundert Prozent gelungen. Hier habe ich einige Gedanken im Kopf was man besser machen könnte und ich freue mich schon auf die Umsetzung.

Das also ist der Plan: die Version 0.2 von ByteCodeDeluxe umsetzen. Dabei die neuen Ideen zur Architektur einarbeiten und, ganz wichtig, die Abstraktion so weit treiben, dass der Großteil des Codes sich für drei Plugins wiederverwenden lässt. Eines für Eclipse, eines für IDEA und eines für Netbeans. Welche neuen Features dabei Eingang finden werden, und welche nicht, bleibt noch zu entscheiden. So ganz zufrieden bin ich mit der Bytecode Ansicht noch nicht, und es wäre schön wenn man den Bytecode nicht nur betrachten, sondern auch editieren könnte. Es gibt noch vieles mehr was schön wäre, aber die Versionsnummern sind ja noch nicht aufgebraucht. Und eines wird es mit Sicherheit geben: ByteCodeDeluxe für Eclipse, IDEA und Netbeans!