Schlagwort-Archive: Eclipse

Vor zwei Tagen ist Eclipse Mars (Version 4.5) erschienen. Voller Vorfreude habe ich mir das neue Release direkt am Erscheinungstag installiert, sowohl im Büro als auch zuhause. Heute habe ich das blöde Mistding immer noch nicht fehlerfrei am laufen. So lautet mein Fazit nach zwei verschwendeten Tagen, in denen ich weitestgehend irgendwelche Fehlermeldungen googlen durfte: Eclipse Mars ist einfach scheiße. Die Vorgängerversion Eclipse Luna hat mir in einem ganzen Jahr nicht soviel Ärger gemacht.

Wo sind „Check for Updates“ und „Install New Software“ hin?

Nach dem Entpacken und dem ersten Start sieht das „Help“-Menü folgendermaßen aus:

eclipsemarsfirst

Auch wenn ich Eclipse mehrmals schließe und wieder starte, ändert sich nichts. Doch sobald ich irgendein Plugin installiere, und Eclipse mich zum Neustart auffordert, verschwinden im „Help“-Menü alle wichtigen Menüpunkte:

eclipsemarssecond

Und sie tauchen auch nicht mehr auf. Neuinstallieren hilft, dann sind die Menüpunkte wieder da, bis sie irgendwann erneut verschwinden. Bis jetzt konnte ich nichts darüber herausfinden. Eclipse mit Administratorrechten zu starten, macht die Menüpunkte kurzzeitig sichtbar, aber nie wieder als normaler User, außerdem ist das kein befriedigender Workaround für diesen Fehler. Andere scheinen von diesem Problem ebenfalls betroffen zu sein, aber eine funktionierende Lösung oder eine Begründung dafür gibt es nicht.

Eclipse%20Mars

Im Büro hatte ich Eclipse zuerst mehr oder weniger versehentlich in einen Pfad mit Leerzeichen installiert. Sowas würde normalerweise gar nicht auffallen, da Programme seit mindestens 15 Jahren damit umgehen können, doch nicht Eclipse: Ein Ant-Build-Script ließ sich ums Verrecken nicht mehr ausführen, da die Eclipse-Ant-Version, die ohne ersichtlichen Grund von irgendeinem Additional Task im Zusammenhang mit SWT abhängig ist, die entsprechende JAR-Datei im Eclipse-Pfad nicht finden konnte. Die Fehlermeldung dazu sah ungefähr wie folgt aus:

The archive: C:\Program%20Files\Eclipse%20Mars\plugins\org.eclipse.swt.win32.win32.x86_64_3.104.0.v20150528-0211.jar which is referenced by the classpath, does not exist.

Stundenlanges Recherchieren im Netz brachte mich nicht weiter, nicht einmal die unnötige Abhängigkeit ließ sich rausnehmen, da der „Remove“-Button schlauerweise immer ausgegraut ist. Der Fehlermeldung konnte ich schließlich bei genauerem Hinsehen entnehmen, dass Ant das Leerzeichen im Pfad mit „%20“ kodieren wollte, was im lokalen Dateisystem nicht funktioniert. Eclipse-Ant versteht offenbar keine Leerzeichen. Das Umbenennen des Installationsverzeichnisses hat dann geholfen, aber eine Lösung ist das ja nicht. Schade um die vergeudete Zeit. Danke für nichts, Eclipse.

Nachtrag vom 29.06.: Inzwischen habe ich herausgefunden, dass dieser Fehler ein registrierer Bug in Eclipse 4.5 ist. Ich bilde mir also zum Glück noch nichts ein.

Zuhause überraschte mich mein eigenes Ant-Build-Script in Eclipse Mars neuerdings mit dieser Fehlermeldung:

No editor descriptor for id org.eclipse.ant.ui.internal.editor.AntEditor

Wenn ich die External Tools Configuration aufrufen will, hagelt es weitere Fehlermeldungen, z.B.:

Exception occurred creating launch configuration tabs

Reason:
No tab group defined for launch configuration type
org.eclipse.ant.AntLaunchConfigurationType

Und damit lässt sich das Build-Script weder vernünftig bearbeiten noch in irgendeiner Form ausführen oder konfigurieren. Wurde Eclipse-Ant heimlich aus der „Eclipse IDE for Java Developers“ entfernt? Eigentlich scheint Apache Ant 1.9.4 dem Paket wie erwartet beizuliegen, aber in der IDE selbst wurde jede Ant-Referenz entfernt. Google weiß zu dem Thema auch nichts. In Eclipse Luna hat das alles noch einwandfrei funktioniert. Beim erneuten Entpacken des Programms war Ant plötzlich wieder da – fragt sich nur wie lange noch. Egal woran es hängt, die Fehler gehen mir mächtig auf die Nerven, und ich hätte gerne, dass das behoben wird.

Cannot complete the install wegen was auch immer

Eclipse ist hässlich, aber zum Glück gibt es Abhilfe: Das Plugin „Jeeeyul’s Eclipse Themes“ lässt die Entwicklungsumgebung einigermaßen brauchbar aussehen und verbessert die Laune beim Arbeiten erheblich. Seit zwei Jahren bin ich ein echter Fan dieses Plugins, und so wollte ich auch Eclipse Mars damit ein wenig aufhübschen. Offenbar ist die Installation aber total schwierig:

Cannot complete the install because one or more required items could not be found. Software being installed: Jeeeyul’s Themes 2.3.0.I20150604-134826 (net.jeeeyul.eclipse.themes.feature.feature.group 2.3.0.I20150604-134826) Missing requirement: Jeeeyul’s Themes 2.3.0.I20150604-134826 (net.jeeeyul.eclipse.themes.feature.feature.group 2.3.0.I20150604-134826) requires ‚org.eclipse.xtend.lib 0.0.0‘ but it could not be found

Im Anschluss bietet der Eclipse Marketplace mir als mageren Ersatz eine hoffnungslos veraltete Version des Plugins an, die mit Eclipse Mars überhaupt nicht kompatibel ist und das Programm entweder im Betrieb zum Absturz bringt, oder erst gar nicht starten lässt, je nachdem ob die Theme bereits im Workspace hinterlegt war, oder erst nachträglich gewechselt wird. Der Eclipse Marketplace ist nicht nur völlig unfähig darin, eine bestimmte Abhängigkeit für mich aufzutreiben, wenn ich ein Plugin installieren will, er ist auch noch so unfähig, dass er mir eine total falsche Version installiert, die die Eclipse-Installation im Endeffekt unbrauchbar macht.

Wegen solch lästiger Kinderkrankheiten erwäge ich zum ersten Mal nach elf Jahren Eclipse endlich links liegen zu lassen, und es stattdessen doch mal mit einer professionellen Entwicklungsumgebung zu versuchen, die mich nicht mit Fehlermeldungen überhäuft und Menüpunkte versteckt.

Nachtrag vom 29.06.: Weiter gehts. Noch nicht einmal ein Update klappt richtig, wenn denn der Menüpunkt ausnahmsweise mal auftaucht:

Unable to read repository at http://download.eclipse.org/releases/mars.
No repository found at http://download.eclipse.org/technology/epp/packages/mars/.

Ich dachte bis heute morgen noch, ich sei mittlerweile lange genug Java-Entwickler, um vor solchen blöden Fehlern gefeit zu sein. Stellt sich heraus, dass man wirklich viel Zeit mit sinnloser Fehlersuche selbst in simpelstem Code verschwenden kann.

Heute schrieb ich etwas in meiner favorisierten Java-IDE Eclipse, das ich in der Art praktisch täglich unzählige Male schreibe:

List<String> myList = new ArrayList<String>();

List und ArrayList wurden mir rot unterstrichen, weil er die Klassen nicht kannte. Es dauert natürlich nur wenige Klicks und Eclipse generiert die fehlenden Imports blitzschnell. So weit so normal. Doch dann wird mir List erneut rot unterstrichen, mit der Fehlermeldung „The type List is not generic; it cannot be parameterized with arguments <String>„.

Ungläubig starrte ich die Fehlermeldung an. Ich war mir eigentlich total sicher, dass List Generics verwendet. Sicherer ging es fast nicht. Die Fehlermeldung sagte also genau das Gegenteil von dem aus, was meiner Ansicht nach den Tatsachen entsprechen sollte. Oder doch nicht? Plötzlich begann ich zu zweifeln. Werde ich etwa schon senil? Wieso ist ArrayList parametrisierbar, aber List auf einmal nicht? Ist das irgendwie sinnvoll?

Ich begann hilflos, die Zeile irgendwie zu modifizieren. War List auf einmal allergisch gegen String geworden? Nein, daran lag es nicht, auch andere Parameter nahm er nicht an. Ich hätte den Parameter weglassen können, oder ich hätte auch direkt ArrayList anstelle von List verwenden können, das hätte funktioniert, aber Eclipse sollte mich doch nicht etwa dazu kriegen, die wichtigsten Programmierparadigmen zu vergessen. Ich vermutete, dass Eclipse einfach mal wieder seine Tage hatte und mich zu Unrecht irgendwelcher Anfängerfehler beschuldigte. An der Zeile war alles in Ordnung, postulierte ich.

Ich begann also doch das Orakel von Google zu bemühen, weil ich offenbar außer Stande war, mir selbst bei solch einem trivialen Problem zu helfen. Eine Quelle behauptete nun, dass es wohl mit dem Compliance-Level des Compilers zu tun hatte, das versehentlich auf eine Version vor Java 1.5 gestellt sein musste, also bevor Generics in Java eingeführt wurden. Ein kurzer Blick in die Compiler-Optionen des Projekts widerlegte das. Mit dem Compliance-Level war alles in Ordnung. In Zukunft also wieder auf konkrete Implementierungen programmieren?

Zum Glück nicht, denn des Rätsels Lösung fand ich direkt im Anschluss, und ich bin erschrocken über die Tatsache, dass ich an dieser Stelle vielleicht erst ganz zuletzt gesucht hätte. Ich habe mich bei den Imports entweder verklickt oder Eclipse hat mich einfach nur auf den Arm nehmen wollen. Als ich List importieren wollte, habe ich wie automatisch die oberste Option ausgewählt, weil das in dem Fall normalerweise immer funktioniert. Ausnahmsweise dachte Eclipse, es wäre besonders witzig wenn ganz oben die wenig bekannte java.awt.List stehen würde, anstelle der sehr viel häufiger genutzten gleichnamigen Klasse java.util.List.

Nun, die AWT-List verwendet tatsächlich keine Generics, Eclipse hat also Recht behalten. Aber der Fehler ist so dämlich, dass es mir eine Lehre war, die Imports allzu leichtfertig zu handhaben. Künftig prüfe ich höchstpersönlich jede einzelne importierte Klasse auf Richtigkeit.

Es gibt Neuigkeiten von Spacola Eclipse. Leider keine bahnbrechenden Neuigkeiten, aber immerhin. Aus irgendeinem mir bislang unerfindlichen Grund habe ich zur Zeit genug Motivation um wieder relativ intensiv an meinem kleinen Remake zu arbeiten. Die letzten Monate habe ich mir den Quellcode immer mal wieder angesehen und ein paar Verbesserungen eingefügt, aber ich habe mich konsequent davor gedrückt, neue Kernfeatures einzubauen, die dringend nötig wären. So darf ich nun (stolz) das Ergebnis der letzten drei Tage präsentieren:

In Spacola Eclipse darf jetzt scharf geschossen werden. Ich habe das Schießen endlich implementiert. Für drei Tage Arbeit ist das mickrig, sagt ihr? Ja ist es. Aber wenn ihr die Mathematikprüfungen im Studium gerade so bestanden habt (so wie ich), dann habt ihr vielleicht eine Vorstellung davon, wie mühsam es ist, sich trigonometrische Operationen, Vektorarithmetik und Koordinatensystemumwandlungen aus dem Kopf herzuleiten ohne danach zu googlen oder ein Mathebuch herzunehmen – vor allem dann wenn die letzte Mathematikvorlesung schon ein paar Jahre her ist. Alles was ich hier mache, lerne ich durch Trial and Error. Wenn ein Algorithmus nicht funktioniert, dann nehme ich ein Stück Papier zur Hand und überlege mir eine Lösung.

Leider gibt es noch nichts worauf geschossen werden kann. Die Gegnersprites sind zwar längst angelegt, aber die Gegner-KI ist praktisch noch „leer“. Zu diesem Zweck hab ich außerdem eine abstrakte Klasse für Gegner angelegt und die wichtigsten Methoden definiert. Leider ist es extrem schwer, das Gegnerverhalten rein aus der Beobachtung des Ergebnisses nachzubilden – also wenn man nicht weiß, was im Hintergrund alles passiert. Ich kann nur versuchen, etwas zu schreiben, das dem erwarteten Verhalten nahekommt.

Der erste Gegner wird der (von mir so bezeichnete) „Peashooter“ sein. Aus dem Handbuch des Originals ist der Name des Schiffs nicht ersichtlich, also hab ich ihn genau so genannt wie er aussieht – wie diese eine Pflanze aus „Plants vs. Zombies“. Er ist einer der wenigen Gegner, die auf den Spieler feuern können, und so ziemlich der erste, dem man im Spiel begegnet.

Unter dem schon seit einiger Zeit existenten Menüpunkt „Spacola“ findet ihr seit heute einige Informationen rund um das Java-Remake des Atari ST-Klassikers Spacola. In Zukunft werde ich dort über Entwicklungsfortschritte berichten und so eine Art Dev Diary bzw. Changelog unterhalten, um mich selbst zu motivieren am Ball zu bleiben. Meinem kleinen Projekt habe ich den Titel „Spacola Eclipse“ gegeben, weil es so mehr nach Remake klingt und weil die Entwicklungsumgebung Eclipse SDK heißt. Dürfte also passen.

Nach wie vor kann ich niemandem versprechen, dass das Spiel wirklich fertig wird. In letzter Zeit bin ich auch nachlässig geworden und hab den Quelltext nur noch unregelmäßig angerührt. Aber ich gelobe Besserung. Für Vorschläge, Hinweise, Requests und Motivationsschreiben bin ich immer erreichbar :)

SpacolaCodeJetzt da ich sowieso schon im Retrofieber bin: Vor zwei Tagen hatte ich die Idee, mich an einem Remake des Dongleware-Klassikers Spacola von Meinolf Schneider zu versuchen. Ich wollte das Spiel endlich für moderne Betriebssysteme wiederauferstehen lassen und was eignet sich für so eine wenig hardwarehungrige Anwendung besser als Java? So gibts das Spiel wenigstens für Windows, Linux und den ganzen Rest. Außerdem gibt es sonst kein Spacola-Remake.

Ursprünglich dachte ich, ich würde sowieso nach zehn Minuten die Geduld verlieren, was auch beinahe geschah. Am ersten Tag hatte ich es nach zwei Stunden kaum geschafft, mit meinem Code ein Fensterchen zu öffnen. Inzwischen arbeite ich aber schon drei Tage daran und das kleine Raumschiff fliegt schon munter durch den nett animierten Sternenhimmel. Grafikausgabe, Spritehandling und die Maussteuerung sind beinahe fertig implementiert. Wenn das in dem Tempo weitergeht, kann ich demnächst die ersten Gegner in meine Levels setzen. Kaum zu glauben wieviel Trigonometrie nötig ist, um eine halbwegs passable Steuerung hinzubekommen.

Wann es eine spielbare Version geben wird, kann ich im Moment noch nicht sagen. Nicht einmal ob ich das Spiel wirklich fertigschreiben werde. Aber derzeit sieht alles ganz gut aus, ich komme schneller voran als gedacht.