Wirthis Blog

Wenn's mal schief geht, dann ordentlich. Beim Programmieren für die Masterarbeit sehe ich plötzlich, dass Eclipse in der Problems-View einen Fehler in einer (geschlossenen, aber vor wenigen Minuten bearbeiteten) Java-Datei meldet. In der Zeile 53 sei ein überflüssiges Symbol "t" - wohl ein Tippfehler. Ich öffne die Datei durch Doppelklick auf den Fehler. Diese öffnet sich, der Editor scrollt allerdings nicht zum Fehler, sondern bleibt am Anfang der Datei stehen. Auch wird kein Fehler-Marker angezeigt - zumindest nicht an der erwarteten Stelle, sondern am Beginn der Datei. Ich scrolle zur betroffenen Zeile 53, finde diese aber nicht. Es gibt eine Zeile 52, eine Zeile 53 - allerdings keine Zeile 53. Folding ist zwar aktiviert für den Editor, allerdings ist die gesuchte Zeile nicht weg gefoldet. Die Zeilennummern-Anzeige im Editor lässt die Zeile 53 beinhart aus. Es zeigt sich, dass Eclipse tatsächlich die fehlerhafte Zeile einfach nicht anzeigt. Das Schließen und neu Öffnen...

Die Freude beim Plugin-Entwickeln war riesengroß: Eclipse compiliert den Code der Plugins zwar fehlerfrei, meldet zur Laufzeit dann aber einen "java.lang.NoClassDefFoundError". Wie kann das sein - Übersetzen geht ja? Meine Anwendung besteht aus mehreren Plugins, die teilweise voneinander abhängig sind. Die Abhängigkeiten sind korrekt definiert. Trotzdem: ein neu erstelltes Plugin enthält Code, der zur Laufzeit nicht gefunden werden kann. Code, der direkt im Plugin in Java-Dateien vorhanden ist und vom Compiler offenbar doch gefunden wird. Um dem Leser dieser Zeilen meinen Leidensweg zu ersparen komm ich gleich zur Lösung, deren Findung mich und meine Kollegen einen halben Tag gekostet hat: Der "." war nicht im Classpath. In der Datei MANIFEST.MF des exportierenden Plug-Ins muss in der Zeile "Bundle-ClassPath:" eben auch ein Punkt stehen: Bundle-ClassPath: . Voila: es geht wieder. Kein NoClassDefFoundError mehr. Nachforschungen haben ergeben: Wenn man ein n...

Das Eclipse-Project bietet ein eigenes Framework zur Erstellung visueller Editoren: das Graphical Editor Framework. Dieses ist zwar eigentlich "sehr super"; man braucht aber einiges an Einarbeitungszeit, bis man mit dem Framework wirklich schnell und effektiv arbeiten kann. Keine all zu große Hilfe dabei ist die - Hilfe. Die erklärt zwar, wie man die einzelnen Klassen benutzt; vergessen wurde aber etwa, zu beschreiben, was die Klassen tun. Wenn ich also bereits weiß, was ich von der Klasse möchte, erfahre ich das. Wenn ich aber absolut keinen Plan von GEF habe, dann Aus diesen Gründen - und um die gute, alte Zeit meiner Tutorials wieder aufleben zu lassen - habe ich ein GEF-Tutorial geschrieben. Es richtet sich an alle Java-Entwickler, die einen raschen Einstieg in GEF suchen. Es soll keine Referenz sein, die alles ganz genau beschreibt, sondern den Entwickler auf dem Weg zum ersten Editor begleiten. Das Tutorial selber ist noch alles andere als unfertig, einige Kapitel fehle...