Software

Java

Java Toolkit-Sync verschluckt Interrupted-Flag

0

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.

goldenpoo

Eclipse Mars ist scheiße

2

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

ATARI

(Retro)² = ZX81 Emulator für Atari ST

3

Eine E-Mail von meinem Blogger-Kollegen Oli – ein gleichgesinnter Atari-ST-Fan und ebenfalls Programmierer – nehme ich heute zum Anlass, einen kleinen Softwarearchäologie-Report zu verfassen. Er sprach mich auf einen alten ZX81-Emulator an; ein Emulator für den Atari ST, den ich seit bestimmt 20 Jahren nicht mehr gesehen habe, und mit dem ich einige der interessantesten Erinnerungen aus meiner Kindheit verbinde. Den Artikel schreibe ich freilich aus der Sicht von jemandem, der das Programm als Kind verwendet hat, und nicht etwa von jemandem, der professionell damit umgehen kann.

ZX81 Emulator: Ein sehr kreatives Tastaturlayout

ZX81 Emulator: Ein sehr kreatives Tastaturlayout

Ich erinnere mich noch sehr gut an dieses kleine aber großartige PD-Programm von Christoph Zwerschke, das zum ersten Mal im Oktober 1990 auf der Beilagediskette des TOS-Magazins veröffentlicht wurde. Ich war kaum sieben Jahre alt und hatte schon ganz grob begriffen, was ein Emulator ist. Dieser hier emulierte einen Sinclair ZX81 – ein kleiner Homecomputer aus England (von dem namensgebenden Erfinder Sir Clive Sinclair), der zum Zeitpunkt meiner Geburt bereits veraltet und Anfang der 90er praktisch museumsreif war. Wenn man den Emulator startet, bekommt man einen Begrüßungsbildschirm zu sehen, und dann nur noch ein Eingabefenster. Das war schon damals nicht unbedingt besonders einladend, wenn man grafische Benutzeroberflächen (wie TOS) gewohnt war, aber ich kannte zum Glück den GFA-BASIC-Interpreter, und der sah ähnlich spartanisch aus. Keine Ahnung, wie ich darauf gekommen bin (vielleicht habe ich ja wirklich die README-Datei gelesen), aber mit der Eingabe von LOAD “” offenbarte sich mir eine fantastische Welt primitiver BASIC-Spiele, und das war für mich in dem Alter das Beste an dem Emulator.

Mein Vater schüttelte den Kopf als er diese äußerst altbackene Klötzchengrafik sah, und er wunderte sich, wie ich damit soviel Spaß haben konnte, wo der ST doch so tolle hochauflösende Monochromspiele und knallbunte Farbspiele hatte. Möglicherweise war das der Moment, in dem ich endgültig erkannte, dass Spielspaß praktisch nichts mit Grafik zu tun hatte, und mit Sound schon gar nicht, denn den gab es sowieso nicht: Der ZX81-Emulator blieb immer stumm. Keine Frage, ich liebte mein Highway Patrol 2, mein Cadaver, und mein Double Dragon, und all die anderen tollen Spiele, die ich in meiner Diskettenbox hatte, aber der ZX81-Emulator löste mit seiner merkwürdigen Schwarz-Weiß-Zeichensatz-Grafik eine wirklich kaum zu beschreibende Faszination bei mir aus.

3D-Monster-Labyrinth: Vor dieser Kreatur habe ich mich gefürchtet

3D-Monster-Labyrinth: Vor dieser Kreatur habe ich mich gefürchtet

Eine ganze Menge Spiele lagen dem Emulator bei, alle in Form von (kaum lesbaren) BASIC-Quellcodes. Mit dem Befehl RUN wurde das geladene Programm gestartet. Das waren ganz unterschiedliche Spiele: Night Driver, eine schwierige Rennsimulation, oder Varianten von Hangman und Centipede gab es, außerdem mit Hamurabi ein zahlenlastiges Resourcen-Management-Spiel, das ich kaum verstand. In Olympiade musste man abwechselnd die Tasten 5 und 8 drücken, damit der eigene Läufer immer schneller wurde, und mit der Taste 0 konnte man dann abspringen (beim Weitsprung). Viele Stunden Spaß hatte ich mit Mazogs, dessen Omikron-Äquivalent Maziacs ich schon kannte – ein Labyrinth voller Riesenspinnen, in dem man eine Schatztruhe finden musste. Daneben gab es mit Star Trek ein aufwändiges Weltraumspiel mit Handlung, an dem ich mich immer wieder versucht habe, obwohl ich noch etwas zu jung war, um die Rätsel zu verstehen.

Es gab noch diverse Programme, die etwa Schaltpläne generierten, oder einen Biorhythmus berechneten. Das hat mich damals aber alles nicht so interessiert. Spannend war noch das Spiel Animals, eine Umsetzung von “20 Questions”. Ohne die Theorie hinter Binärbäumen zu kennen, hatte ich natürlich Schwierigkeiten mir vorzustellen, wie der Computer am Ende praktisch jedes Tier erraten kann. Das mit Abstand gruseligste Spiel war das 3D-Monster-Labyrinth. Der Spieler musste ein zufällig generiertes Labyrinth in der Ich-Perspektive durchlaufen, während am anderen Ende des Labyrinths ein Monster umherirrt, das seinerseits den Spieler sucht. Ich kann bis heute nicht sagen ob das Monster sich in Echtzeit bewegt, oder doch nur rundenbasiert, aber ihm versehentlich zu begegnen, hat mich immer wieder erschreckt. Es war auf jeden Fall ein tolles Beispiel für ein sehr simples Spiel mit Suchtfaktor, das im besten Fall zweckmäßige Grafik und absolut keinen Ton hatte. Also entweder war ich schon damals wirklich verloren, oder diese Spiele hatten einfach einen gewissen Reiz.

Star Trek: Klötzchenwelten mussten mit Hilfe des Ziffernblock erforscht werden

Star Trek: Klötzchenwelten mussten mit Hilfe des Ziffernblock erforscht werden

Kaum zu glauben, aber wahr: Christoph Zwerschke, der Entwickler des ZX81 Emulator, ist sogar noch mit einer eigenen Webseite im Internet vertreten (letzte Änderung allerdings im März 2001!), und er bietet dort die letzten Versionen seiner alten ST-Programme an, darunter natürlich auch dieser wunderbare Emulator. Extra für ein paar Screenshots habe ich daher den ST-Emulator angeworfen, um nach über 20 Jahren den ZX81-Emulator anzuwerfen, um dessen grobpixelige Spiele mal wieder anzuwerfen und digital abzulichten. Quasi eine kleine Emulatorception. Oder Retro im Quadrat. Und tatsächlich, ich konnte mich noch an so manches Bedienungsdetail erinnern. Und mit der HELP-Taste kann man sich ja im Notfall noch das Tastaturlayout einblenden lassen. Vielleicht spiele ich nochmal kurz eine Runde 3D-Monster-Labyrinth. Retroflash in 3 … 2 … 1 …

Windows

Not so monthly rant: Die wertlose Windows-Dateisuche

4

Lange habe ich mich nicht mehr so sehr über etwas geärgert wie die Windows-Dateisuche. Aus einem bestimmten Ordner mit sehr vielen unterschiedlichen Dateien wollte ich anhand eines entsprechenden Namensmusters einige davon in einen anderen Ordner verschieben. Nichts leichter als das, dachte ich mir, denn die Windows-Suche unterstützt ja schließlich Wildcards (“*” und “?”), und auf den Kopf gefallen bin ich zum Glück auch nicht. Die erwartete Trefferliste lieferte mir die Suchfunktion in Nullkommanix. Mittels Ausschneiden und Einfügen waren mehrere hundert Dateien blitzschnell an den neuen Ort verschoben.

Durch Zufall fiel mir eine Datei ins Auge, die in dem neuen Ordner aber definitiv nichts verloren hatte. Hat die Windows-Suche sich da ein wenig vertan? Konnte ja eigentlich kaum sein. Vielleicht habe ich beim Markieren der Dateien irgendetwas verkehrt gemacht? Auch unwahrscheinlich. Um sicherzugehen, machte ich den Verschiebevorgang rückgängig und führte die Suche erneut aus. Wieder wollte ich die gefundenen Dateien verschieben. Und wieder waren Dateien dabei, die nicht auf das Namensmuster zutreffen konnten. Spinnt Windows oder versagt hier der Faktor Mensch? Ich beschloss also, den Test zu machen:

windowssuche

Was für ein unbrauchbarer Dreck ist das denn bitte? Die Windows-Dateisuchfunktion ist völlig wertlos! Sie hält sich nicht an das Pattern, das ich eingegeben habe, und spuckt neben den richtigen auch falsche Treffer aus. Die Klammern werden einfach ignoriert, so als hätte ich sie nur aus Spaß eingegeben. Meine Recherche im weltweiten Netz bestätigt meine Vermutung: Microsoft hält nichts von Konventionen, sondern bastelt lieber wieder irgendeinen eigenbrötlerischen Schrott zusammen, den man als professioneller Nutzer nicht vernünftig verwenden kann. Das “Escapen” der Klammern mit Backslashes oder Punkten bringt leider nichts, Windows scheint meine Eingabe nur als grobe Empfehlung zu betrachten. Was richtige Suchergebnisse sind, muss ich offenbar gänzlich dem Betriebssystem überlassen. Die Suchfunktion genügt meinen Ansprüchen hier leider absolut nicht. Bevor ich mir die Microsoft’sche Syntax zur Dateisuche anlerne, sofern eine solche überhaupt existiert, nehme ich lieber ein ordentliches Third Party Tool, mit dem man arbeiten kann.

Beinahe hätte ich meine Dateien unbewusst falsch sortiert. Na danke, Microsoft, ihr verdammten Trolle. Wer weiß wie oft ich darauf bislang schon hereingefallen bin ohne es zu merken. Wie schwer kann es sein, eine Suchfunktion mit Wildcards richtig zu implementieren. Ich verlange ja gar nicht, dass hier reguläre Ausdrücke ausgewertet werden, aber eine simple Suchfunktion, die keinen Mist baut, wäre mir WIRKLICH wichtig. Echt mal.

So habe ich nun in meiner Verzweiflung einige – wie sich herausstellte – ebenfalls ziemlich nutzlose Tools heruntergeladen, die meine Erwartungen nicht erfüllen können, darunter “Everything”, “Snowbird”, “Locate32″ und “UltraSearch”. Entweder ließ sich die Suche nur auf (langwierig) vorindizierte Festplatten anwenden (und ich wollte nicht drei Stunden auf mein Suchergebnis warten müssen), oder die Suche ließ sich überhaupt nicht auf Verzeichnisse, sondern im Fall von “Everything” nur auf ALLES anwenden, oder die Suche kannte keine Wildcards, was ich bei einem Dateisuch-Tool als übles Versäumnis betrachte. Nun habe ich schließlich den “FreeCommander” ausprobiert. Der hat alle gewünschten Dateien problemlos gefunden, mit exakt demselben Suchmuster, wie ich es zuvor dem Windows Explorer vorgesetzt hatte – und zwar im Gegensatz dazu fehlerfrei.

Java

Kleines Quellcode-Gruselkabinett II

14

Weil es so lustig war und ich neues Material gesammelt habe, denke ich, dass es an der Zeit ist, das Quellcode-Gruselkabinett mit einem zweiten Artikel fortzusetzen, womöglich zu beenden. Der (nicht näher definierte) Praktikant aus dem ersten Teil hat wieder zugeschlagen und hocheffizienten und extrem sinnvollen Java-Code produziert. Diese Glanzleistung moderner Softwareentwicklerkunst wollte ich denjenigen meiner Leser, die über Programmierkenntnisse (und Englischkenntnisse) verfügen, auf keinen Fall vorenthalten. Wer von Programmieren überhaupt nichts versteht, der wird an diesem Artikel wie gewohnt leider nichts finden können.

Der Praktikant ist offenbar ein großer Fan davon, toString() auf String-Objekten aufzurufen, vielleicht erhofft er sich dadurch noch stärkere Typsicherheit mit Netz und doppeltem Boden oder sowas. Jedenfalls Code wie der obige begegnet mir leider immer häufiger. Solchen Murks mache ich bei Sichtung auch sofort wieder raus.

Ebenfalls ein ständiger Begleiter in seinem Code: Die Angst, dass eine neu (=leer) angelegte Collection vielleicht doch nicht so leer ist, wie sie vorgibt zu sein. Anders kann ich mir nicht erklären, wieso der Praktikant gleich nach dem Erstellen einer leeren Collection diese leert. Womöglich hat er sich hierbei etwas gedacht, ist aber völlig unnützer Code. Ein damit sehr verwandtes Problem ist das folgende:

Aus der API-Dokumentation der oberen Methode: “The Calendar returned is based on the current time in the default time zone with the default locale.“. Der Knackpunkt ist, dass das zurückgegebene Kalender-Objekt immer bereits mit der gegenwärtigen Uhrzeit initialisiert ist. Hier (zur Sicherheit oder aus Unkenntnis) nochmals Uhrzeit und Datum zu setzen und dafür extra ein neues Date-Objekt zu erstellen, ist kompletter Unfug. Überhaupt: Wieso geht er davon aus, dass der parameterlose Konstruktor von Date() die aktuelle Uhrzeit liefert, aber bei Calendar soll selbiges System nicht funktionieren? Nett auch die Wahl des Variablennamens “actCal” für den Kalender. Er dachte wohl, “actual calendar” sei eine brauchbare Übersetzung für das, was er ausdrückten wollte. Ich lese da aber irgendwie immer nur “Aktkalender”.

Auch so ein Codekonstrukt, worüber man diskutieren sollte: die Getter-Methode für private Konstanten. Wieso nicht gleich die Konstante als public deklarieren, dann kann man sich das Rumgeeiere sparen. Bei Konstanten durchaus sinnvoll. Aber als verwandtes Problem sei angemerkt, dass der Praktikant zum Beispiel ganz gerne auch mal simple Getter-Methoden innerhalb derselben Klasse aufruft, in der sie definiert werden – anstelle der sichtbaren Variable. Kapselung schön und gut, aber damit ist doch eigentlich Kapselung von der Außenwelt gemeint. Das scheint jemand nicht so richtig verstanden zu haben.

Namenskonventionen für Methoden sind auch so ein Problem für den Praktikanten. Der Name der Methode sagt leider nichts darüber aus, was der Rückgabetyp sein könnte. Im Fall von “componentParser” ist noch nicht einmal eine Tätigkeit erkennbar. Da meldet die als Frage formulierte Methode “isActive” eine komplexe Hashmap zurück, und die etwas umständlich benannte Methode “getTheParsedSysInfoComp” liefert nicht etwa “die kompletten Systeminformationen” zurück, sondern einen Wahrheitswert – was auch immer dieser aussagen soll. Immer wieder lustig mitanzusehen sind Methodennamen, die erkennen lassen, dass sich dabei wohl jemand beim Ausdenken einen abbrechen musste, etwa “isLoadTimeFromOneSystemOverTime”.

Englisch scheint ohnehin nicht so seine ultimative Stärke zu sein, vor allem wenn die (netterweise konsequent, wenn auch unnötigerweise) im Englischen gehaltenen Kommentarzeilen nur so vor Denglisch triefen. Da wird aus “Pfade herausfiltern” schonmal “filter the path outside”, oder das weibliche Possessivpronomen “her” wird auf Systeme und _ihre_ Eigenschaften angewandt. Wenn man kein Englisch kann, sollte man vielleicht nicht unbedingt versuchen, alles immer englisch schreiben zu wollen, oder zumindest mal ein paar Vokabeln nachschlagen, bevor man in die Tasten haut.

nach oben