Beiträge mit tag "Java

SPACOLA Eclipse WIP 0.63

0

Linux-Support

Palim palim! Der unregelmäßige SPACOLA-Remake Fortschrittsbericht ist da! Och, keine Sorge, viel Fortschritt gibts nicht. Aber es gibt immerhin was zu sehen. In den vergangenen Monaten habe ich weitestgehend unter Linux Mint weiterentwickelt, und leider ging auch ein nicht unwesentlicher Teil der Zeit dafür drauf, Probleme zu beheben, die das Spiel nur unter Linux hatte. Zum Beispiel habe ich es lange Zeit nicht hinbekommen, dass das GUI-Fenster sowohl unter Windows als auch unter Linux immer exakt die gewünschte Größe hat. Wenn es unter Linux gepasst hat, war es unter Windows falsch. Wenn ich es dann für Windows korrigiert habe, war die Linux-Version plötzlich wieder schief. Wenn das programmatische Resizing des Fensters endlich überall funktionierte, ging dafür die Menüleiste nirgends mehr. Habe ich eine Sache repariert, geht eine andere Funktion kaputt. Es war wie bei einem Teppich, bei dem man eine Unebenheit mit dem Fuß ausbessern will, die sich dann nur immer wieder woanders auftut. Da soll mir nochmal einer sagen, Java sei wirklich plattformunabhängig. Swing ist es jedenfalls schonmal nicht. Ich habe viele graue Haare bekommen bis es endlich perfekt war. Die aktuelle Version funktioniert somit einwandfrei unter Windows und Linux.

Neue Artworks

In der Zwischenzeit habe ich viel mit neuen Artworks experimentiert und dabei kräftig mit GIMP gebastelt. Lange Zeit habe ich darüber gegrübelt, wie ich die Titelgrafiken designen soll, so dass sie sehr nahe am Original bleiben, und trotzdem viel Spielraum für eine Neuinterpretation im Sinne des Remakes erlauben. Mittlerweile habe ich ein mehr oder weniger einheitliches Design für den Fensterhintergrund, für den About-Dialog, für die Webseite und für den Splash-Screen beim Laden entworfen. Ja, das Remake hat jetzt einen eigenen Ladebildschirm, weil das Starten auf manchen Systemen doch schon mal die eine oder andere Sekunde länger dauern kann. Die Grafiken sind natürlich bei weitem nicht perfekt, aber ich glaube, man kann das erstmal so stehen lassen. Der Wiedererkennungswert ist schonmal ganz ordentlich.

Spiel laden und speichern

Die Funktionen zum Laden und Speichern der Spielstände sind jetzt endlich fertig. Genau wie im Original kann der Kaffee-Button genutzt werden, um den aktuellen Spielstand zu speichern. Zusätzlich gibt es außerdem die Möglichkeit, beliebig viele weitere Spielstände zu speichern und auch via Dateiauswahl wieder zu laden. Im Moment bezieht sich das Speichern jedoch nur auf den Zustand zwischen den Levels, nicht direkt IM Spiel. Ob eine solche Funktion noch nachgereicht wird, und ob das jemandem viel hilft, muss ich noch klären. Jedenfalls ist es klasse, dass man nun tatsächlich den Spielfortschritt in eine Datei persistieren und so jederzeit fortsetzen kann. Damit wäre ein wichtiger Punkt von meiner Todo-Liste gestrichen.

GEM-Schriftarten und Highscore-Liste

Die Remake-GUI verwendet jetzt konsequent drei verschiedene Original-TOS/GEM-Systemschriftarten, um so zusätzlichen Wiedererkennungswert zu generieren. Die Atari ST-Schriftarten erkennen Fans sofort. Nicht dass diese Schriftarten besonders hübsch oder gut lesbar wären, aber sie geben einem echten Nostalgiker doch schnell ein warmes Gefühl. Die Highscore-Liste wurde von mir deutlich erweitert. Zusätzlich wird nun der Highscore-Zeitstempel gespeichert, außerdem die Komplettierungsrate des Spiels in Prozent, damit man die Angaben besser vergleichen kann. Außerdem werden jetzt beliebig viele Einträge gespeichert. Im gerenderten Spiel selbst tauchen dann allerdings nur die ersten zehn Einträge auf, und dann auch nur deren Namen und Punktestand – die übrigen Werte werden einfach versteckt, um so nah beim Original zu bleiben wie möglich.

Post-Processing-Filter dank neuer Rendering-Methode

Besonders wenn man das Spiel auf Pixelverdoppelung stellt, also in der Auflösung 1280×800 spielen will, bremsen etwaige Post-Processing-Filter das Spiel leider so stark aus, dass es kaum noch Spaß machen kann. Zwar gibt es im Moment mit der Invertieren-Funktion nur einen einzigen Filter, aber ich wollte dort in Zukunft noch mehr Filter-Optionen anbieten, um den Look des Spiels den eigenen Bedürfnissen anzupassen. Nun, meine Idee war es, das Post-Processing immer nur auf die gerenderte Spielgrafik (in niedriger Auflösung) anzuwenden, und erst dann das Ergebnis hochzuskalieren. Würde ich erst hochskalieren und dann die Filter auf die hohe Auflösung anwenden, wäre das logischerweise viel langsamer. Leider machte dieser neue Ansatz es nötig, einige Teile des Renderings umzuschreiben, um die neue Reihenfolge der Arbeitsschritte zu ermöglichen. Zusätzlich implementierte ich eine Filterklasse, die es erlaubt, unbegrenzt viele verschiedene Filter ins Bild „einzuhängen“, um die Grafik zur Laufzeit jederzeit zu ändern. Der neue Code funktioniert wirklich erstaunlich schnell und schön flexibel. Die Änderungen haben sich gelohnt.

Neuer Anvisieren-Algorithmus für Geschütze

Man mag es kaum glauben, aber ich habe wirklich übermäßig viel Zeit in den Algorithmus für das Anvisieren der Geschütze investiert. Ich dachte ursprünglich, es genau richtig hinbekommen zu haben. Dann fiel mir jedoch beim Nachspielen des Originals auf, dass die Geschütze beim ST-Klassiker nie daneben feuern, egal wie schnell und egal wohin der Spieler sich bewegt. Das bedeutete, dass die Geschütze nicht nur den Winkel zum Spieler und dessen Bewegungsgeschwindigkeit in die Berechnung des Vektors einbeziehen, sondern bei bekannter eigener Geschossgeschwindigkeit auch den Abschusswinkel exakt so berechnen, dass die Geschosse den Spieler an einem unbekannten Punkt zielsicher treffen. Am Ende habe ich mir das Problem bestimmt ein dutzend Mal auf einem kartesischen Koordinatensystem skizziert und versucht herzuleiten, wie der Winkel berechnet wird. Ich wusste wie lang der Vektor sein dürfte, ich wusste nur nicht, wo er den anderen Vektor schneiden würde. Am Ende fand ich eine Lösung, indem ich den Spielervektor von der Position des Geschützes aus nahm, einen Kreis mit Radius der erlaubten verbleibenden Vektorlänge um diese neue Koordinate berechnete um die Schnittpunkte mit dem anderen Vektor zu finden. Der Vektor vom Geschütz zu diesen Schnittpunkten muss dann der Abschussvektor sein. Das ist dann zwar eine vergleichsweise teure Berechnung, aber sie funktioniert perfekt.

Levelgenerator-Verbesserungen

Den Levelgenerator habe ich wieder geringfügig verbessert. So funktionieren die Floodfilling-Methoden für Konfigurationen von Stationen, Powerups und schwarzen Löchern jetzt besser und erlauben auch die Übertragung von Parametern, wie aus dem Levelskript vorgegeben. Der Levelgenerator setzt nun korrekt die Deploy-Distanz für Gegner, die Deployment-Rate und die Anzahl gleichzeitig erlaubter Gegner. Außerdem habe ich eine Funktion eingebaut, die ich nur als „Shield-Powerup-Stacking“ bezeichnen kann, die mir im Original sehr merkwürdig vorkam. Ich bin mir immer noch nicht sicher, ob das ein Bug ist, oder ob es beabsichtigt war. Jedenfalls kann der Spieler seine Schutzschild-Option zeitlich deutlich verlängern, wenn er mit aktiviertem Schutzschild noch ein weiteres Schild-Powerup einsammelt. Ich müsste wohl auch noch prüfen, ob dieses „Feature“ in jeder Spacola-Version auftritt, oder nur in einer bestimmten. Jedenfalls ist das nun ebenfalls im Remake perfekt nachgebildet.

So, das waren wieder einige kleine Einblicke in die Entwicklung der vergangenen Monate. Ich bleibe am Ball und arbeite mich langsam voran. Der Quellcode umfasst inzwischen über 40.000 Zeilen und wächst stetig weiter.

SPACOLA Eclipse WIP 0.60

0

Okay, ich habe wieder einmal sämtliche mir selbst gesetzten Deadlines verschlafen. Das Remake wurde leider doch nicht zum 25-jährigen Jubiläum fertig, und wird es vermutlich auch noch eine ganze Weile nicht. Scheiß drauf. Ich bin gleichzeitig Opfer meiner eigenen Faulheit und Penibilität geworden. Das Problem mit Arbeit nach der Arbeit ist, dass sie oftmals keinen Spaß macht, egal wie sehr einem das Zeug am Herzen liegt. Aber hey, ich habe Urlaub – Zeit für mehr Arbeit. Und das Wichtigste ist doch: Ich bin wieder dabei! Vor wenigen Tagen habe ich mit der Arbeit an der Version 0.60 begonnen.

Ich habe eine neue Spritebibliothek geschrieben, die sich um das Laden, Konvertieren und Verwalten der vielen kleinen Grafikdateien kümmert. Und diese Spritebibliothek kennt neuerdings auch jeweils die Monochrom- und Farbversion jeder einzelnen Grafik. Bisher waren dies verschiedene Klassen, die immer jeweils getrennt voneinander angepasst werden mussten, und auch der Wechsel von Monochrom nach Farbe hätte bisher viele Codeanpassungen erfordert. Nun wird es möglich, direkt im Client mit einem simplen Mausklick die Darstellung zu wechseln. SPACOLA Eclipse kann endlich richtig mit Farbe umgehen. Da aber noch weit über 90% der Sprites nur monochrom vorliegen, werde ich da irgendwann noch wahnsinnig viel Zeit investieren dürfen. Bisher gibt es nur vereinzelte Sprites in Farbe zu sehen.

Die Farbsprites haben aber noch keine Priorität. Zunächst muss der Classic-Modus fertiggestellt werden, und das ist nach wie vor nicht so einfach wie es klingt. Die Gegner-KI macht mir Sorgen, denn egal wie ich es anpacke, es verhält sich alles nie so ganz wie es sollte, oft scheitert es schon am Ansatz. Dafür habe ich erst zuletzt ein komplettes Explosions-Spriteset hinzugefügt, das mir bisher nicht aufgefallen ist. Es scheint also doch nicht so klar zu sein, dass ich inzwischen wirklich alles aus dem Spiel extrahiert habe. Und ich habe anhand eines Memory Dumps die Zuweisungen der Sounddateien korrigiert, also welcher Sound im Originalspiel welchen Dateinamen hatte. Bislang musste ich dazu raten, und scheinbar lag ich oft falsch. Immerhin konnte ich hier nun einige Fehler korrigieren und so manche Zuweisungen bestätigen, auch wenn es bei anderen Einträgen weiterhin beim Raten bleibt, da der Memory Dump nur eingeschränkt Aufschluss gibt, auf Grund der Art wie die Sounddateien im Original nachgeladen werden können.

Ich hoffe ich werde noch diesen Dezember einige vorzeigbare Fortschritte vermelden können. Kleine Schritte, Tag für Tag. Macht es die Sache besser oder schlimmer, wenn ich jetzt verkünde, dass das Remake in jedem Fall zum 30. Jubiläum im Jahr 2021 fertig sein wird? Hey, wieso werft ihr denn jetzt mit überreifen Tomaten und faulen Eiern nach mir? Okay, okay, ich fang ja schon an…

SPACOLA Eclipse WIP 0.57

0

Berichte über das Ende von SuccessDenied sind stark übertrieben. Ich hatte in letzter Zeit weder besonders viele Themen über die ich schreiben wollen würde, noch war ich überhaupt in der Stimmung, etwas zu schreiben. Beruflich bin ich zur Zeit unabkömmlich. Hinzu kommt, dass ich seit meiner letzten Erkältung vor über fünf Wochen zwar längst nicht mehr krank bin, aber leider auch nicht richtig gesund. Wieder einmal schleppe ich einen wirklich besonders hartnäckigen, unproduktiven Husten mit mir herum. Mehrmals täglich inhaliere ich daher mit meinem Kompressor-Druckluftinhalator Kochsalzlösung mit Mucosolvan, schmiere mich mit Mentholsalbe ein, trinke Hustenlöser, nehme Tropfen ein – die ganze übliche Palette eben, ohne dass irgendetwas davon irgendwie helfen würde. Mit meinen guten Genen bin ich schon sehr gesegnet.

Aber: Wenn die Gesundheit eines Tages zurückkehrt, bin ich sicher, dass ich auch meine gute Laune zurückerhalten werde. In der Zwischenzeit ein kleines Update zum SPACOLA Eclipse Remake-Projekt. Das Projekt steht ganz und gar nicht still, sondern wird wöchentlich mit Änderungen und Neuerungen versehen. Die aktuelle WIP-Version 0.57 vom Juli bringt wieder viele kleine neue Funktionen mit, und sogar eine größere. Aber auch ein paar Änderungen der vorhergehenden Versionen dürfen hier nicht unerwähnt bleiben. Der nüchterne Screenshot soll einen Einblick in das Debug-Menü geben, das ich um einige Einträge erweitert habe. Beim Testen sind die vielen Kommandos äußerst hilfreich, sonst spielt man sich dumm und dämlich, wenn man zum 50. Mal dieselbe Stelle im Code geändert hat.

spacolaeclipse57

Remake-Technik

Die 2D-Grafikengine zeigt jetzt bei Bedarf ein paar Dinge an, die das Original nicht hatte: Sektorgrenzen, Hüllkreise, Objekttypen, Spielernamen (für den Multiplayer-Modus), außerdem natürlich die Partikeleffekte, Interpolation und Pixelvergrößerung. Mal davon abgesehen, erlaubt es das Remake, einige Limitierungen des Originals aufzuheben, die damals vermutlich aus Performancegründen nötig waren. Beispielsweise Objekte, die sich zu weit vom Spieler entfernt hatten, wurden im Original aus dem Spiel genommen. Heute könnte man diesen Löschmechanismus herausnehmen und dadurch eine persistentere Spielwelt bekommen. Der Dongleware-Fadein/Fadeout-Effekt, den ich vor ungefähr 4 Jahren mühsam implementiert hatte, war leider fehlerhaft. Inzwischen ist er eine absolut pixelgetreue Nachbildung.

Maforianer-Gegner fertig

Es hat lange gedauert und mir sind dabei viele graue Haare gewachsen: Der Maforianer, einer der ersten drei Gegner, ist mehr oder weniger komplett fertig. Das Bewegungsmuster dieses Gegners ist vermutlich eines der einfachsten im Spiel, aber bei weitem nicht so leicht nachzuimplementieren, wie man meinen möchte. Inzwischen bin ich an einem Punkt angelangt, wo mein Ansatz der Vorlage nahe genug kommt, so dass man es vorerst so lassen könnte. Dadurch bin ich auch auf die Spur eines neuen mathematischen Ansatzes für die Schiffsnavigation der Gegner gekommen – und habe zufällig auch die Lösung für das Problem mit dem Magnetismuseffekt gefunden. In der Folge bewegen sich die Gegner jetzt realistischer, und die Anziehung von Containern, Waren und Piraten sieht viel besser aus als vorher. Der Maforianer hetzt jetzt dem Spieler permanent hinterher, jagt ihm nach Möglichkeit die Lieferwaren ab und flieht damit zu seiner Piratenstation. Es ist noch nicht alles hundertprozentig, aber es ist besser als nichts. Fehlen für den ersten Level also nur noch zwei weitere Gegner, mal sehen wann mir das gelingt.

Abspann

Im Remake kann man sich – genau wie im Original – das „Zertifikat“, also die Siegerurkunde ausdrucken lassen, sobald man den letzten Level gewonnen hat. Zusätzlich gibt es im Remake nun einen echten Abspann (die Closing Credits), in dem viele beteiligte Personen genannt und Danksagungen zum Ausdruck gebracht werden. Diese kleine Erweiterung wollte ich in jedem Fall im Remake drin haben, denn sie macht ja schließlich auch nichts kaputt. Mir fällt tatsächlich nun außerhalb des laufenden Spiels nichts mehr ein, das ich noch nicht fertig habe. Eigentlich eine gute Nachricht.

Timings

Timings sind mir seit einigen Monaten ein großes Ärgernis gewesen. Nachdem ich am Anfang meistens gesagt habe „Diese oder jene Animation läuft ungefähr 4 Sekunden“ und das dann auch so eingebaut habe, ging ich nun endlich dazu über, die exakte Anzahl Frames zu zählen. Wenn dann beispielsweise 270 Frames herauskommt, muss ich das wiederum umrechnen auf die Zielframerate von aktuell 50 fps. Das wären dann etwa 187 Frames, damit die Animation genauso lange läuft. Ähnlich verhält es sich mit den Konstanten für Gegnerverhalten: Wenn ein bestimmter Gegner 120 Frames braucht, um sich um 180 Grad zu drehen, dann braucht derselbe Gegner im Remake dafür nur noch 83 Frames. Und da sich die Framerate beliebig einstellen lassen wird, muss diese Berechnung wiederum variabel sein. Zusammengefasst habe ich viel Zeit damit verbracht, die Dinge, die eigentlich schon fertig waren, nun auch bezüglich der Original-Timings anzupassen.

Gegner-Deployment und -Redeployment

Das Deployment und Redeployment von Gegnern ist nun wesentlich näher am Original. Alle paar hundert Frames wird ein Gegner in der Station generiert. Dann beginnt dieser sich zu drehen, und zum Spieler auszurichten. Wenn die Ausrichtung stimmt, gibt er Schub und beginnt die Jagd. Dafür gibt es eine Gegner-Warteschlange, die sich aus den Anweisungen der Gegnerkonfigurationen im Levelskript zusammensetzt, und es gibt die Redeployment-Warteschlange für Gegner, die gestohlene Ware abgeliefert haben. Leider verstehe ich den Zusammenhang mit den Levelskripten noch nicht so ganz, daher ist die Unschärfe hier sehr groß. Ich kann aktuell nur nachbilden was ich sehe, und viel sehe ich nicht.

Es sind wie gesagt viele Kleinigkeiten, die nach und nach besser werden. Das Ziel für den ersten komplett spielbaren Level ist schon sichtbar, jetzt heißt es dranbleiben und das Tempo steigern. Die zwei verbliebenen Gegnertypen (für Level 1) werde ich wohl in Kürze angehen müssen, und mich zur Not auch damit anfreunden, wenn das Ergebnis dann nicht perfekt wird.

Java Toolkit-Sync verschluckt Interrupted-Flag

3

Da mir im Moment der Sinn nicht ganz nach irgendeinem Politikum steht, worüber ich meinen Senf ausgießen müsste, werde ich vorerst noch mehr Softwareentwickler-Kram posten, mit dem ich die geneigten, aber uninteressierten Leser erfolgreich abschrecken kann. Wir danken für Ihr Verständnis.

Wer sich im Internet gezielt über aktives Rendering mittels Canvas in Java informiert, also etwas, das direkt im Zusammenhang mit Java-Spieleentwicklung steht, der wird wahrscheinlich irgendwann über die Methode sync() in java.awt.Toolkit stolpern, also meistens in der Form Toolkit.getDefaultToolkit().sync(). Nun gehe ich stark davon aus, dass die meisten Entwickler diese Codeschnipsel als gegeben ansehen und 1:1 in ihre eigene Klasse einfügen, da sie wahrscheinlich vielfach erprobt sind. So war das bei mir anfangs leider auch. In einem eigenen Render-Thread habe ich Bilder gerendert und anschließend brav das Toolkit „synchronisiert“, was laut Dokumentation irgendwie „gut für Animationen“ ist.

Seit der Umstellung auf aktives Rendering jedoch hatte ich plötzlich Schwierigkeiten damit, den Render-Thread mittels interrupt() vorzeitig zu stoppen, also etwa wenn der Nutzer das Rendering über das Menü beendet oder wenn ein bestimmtes Ereignis auftritt. Zuvor war das nie ein Problem gewesen. Neuerdings läuft der Thread in drei von vier Fällen einfach weiter, sobald ich ihn gezielt unterbrechen will. Das war eine mittlere Katastrophe, denn ich konnte mich jetzt nicht mehr darauf verlassen, dass das Programm das macht, was ich davon erwartete. Mein Programm funktionierte so nicht mehr, und ich wusste nicht, was ich falsch gemacht haben könnte.

Etwa einen halben Tag hat es gedauert, bis ich den Fehler gefunden hatte: java.awt.Toolkit.sync() verschluckt ganz frech das Interrupted-Flag. Es scheint leider wirklich so zu sein. Die Implementation der Java Virtual Machine von Oracle ist hier offenbar fehlerhaft, denn alles funktioniert einwandfrei wenn ich auf sync() verzichte. Sobald ich die Zeile verwende, klappt das Unterbrechen des Threads nicht mehr. Meine Vermutung ist daher, dass das blockierende sync() das Interrupted-Flag mittels interrupted() abfragt (und dadurch löscht!), und dann leider nicht mehr setzt und leider auch keine Exception wirft. Es verschluckt die Thread-Unterbrechung völlig. So wird dieser Mechanismus sogar ganz offiziell in der Java-Doku erklärt:

if (Thread.interrupted()) // Clears interrupted status!

Nun hält sich Oracle selbst nicht daran. Ich habe anschließend in meinem Code keine Möglichkeit mehr, diese Unterbrechung zu erkennen und gegebenenfalls selbst eine InterruptedException auszulösen. Oracle hat hier eindeutig Scheiße gebaut, denn eigentlich ist das Konsens, das Interrupted-Flag nach dem Löschen erneut zu setzen, damit die Unterbrechung nach oben eskaliert werden kann, so dass auch andere Programmteile auf die Unterbrechung korrekt reagieren können. Hier wurde ganz einfach geschlampt.

Und was macht sync() eigentlich? Tja, keine Ahnung. So ganz scheint das nämlich niemand zu wissen. Ich liebe es, wenn die Java-Dokumentation von Oracle so explizit ist, dass man trotzdem keine Ahnung hat, was genau vor sich geht. So auch zur Methode sync() der Klasse Toolkit:

void java.awt.Toolkit.sync()

Synchronizes this toolkit’s graphics state. Some window systems may do buffering of graphics events.

This method ensures that the display is up-to-date. It is useful for animation.

Wenn jemand mal im Internet in einschlägigen Entwicklerforen versucht danach zu fragen, was das genau bedeutet, wird die Frage mit „synchronizes the graphics state“ „beantwortet“, und anschließend als Off-Topic geschlossen. Zurecht wurde wenigstens noch darauf hingewiesen, dass das die Frage kaum beantwortet.

Da ich weder sagen kann, was die Methode macht, in welchen Fällen ich sie brauchen könnte, und welche Vorteile oder Nachteile damit zusammenhängen, werde ich auf sync() gerne verzichten, schon da ich mit dem Interrupt-Problem einen ziemlich schwerwiegenden Fehler entdeckt habe, den ich nicht bereit bin zu akzeptieren – ganz egal wie toll die Funktion ansonsten arbeiten möge.

Eclipse Mars ist scheiße

4

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

nach oben